There are three components to having a working virtio interface. They are:

1. A specification, preferably documented in the upstream OASIS VIRTIO specification
2. A device driver, usually in an OS kernel like Linux*
   1. this is sometimes referred to as a front-end
3. A device implementation
   1. this is sometimes referred to as a back-end
   2. often this is part of the hypervisor or Virtual Machine Monitor (VMM)

Project Stratos mostly focuses on working with existing specifications either already in the released version of the spec or already accepted into the working draft of the next version. Some of the Project Stratos works to support restricted memory views may also result in new proposals for VIRTIO transports which will also be submitted for inclusion in the specification.

While Linux already has a large number of virtio devices will be directly accessible to a Linux kernel. For example, the RPMB device isn't exposed directly to a kernel but to a secure layer of the firmware which then provides a secure storage facility to the OS.

Generally, the backend of a VIRTIO device is either part of the hypervisor, or it's associated Virtual Machine Monitor. One of the main goals of Stratos is to achieve as much re-use as possible across multiple hypervisors. The principle approach to this is by implementing each backend as a standalone vhost-user daemon. The details of setting up the memory mapping and initial configuration of the hypervisor can be left to a VMM or stub launcher, and the actual device emulation is achieved with simple POSIX semantics. We are also investigating using Rust-vmm as a portable safe backend for these devices.