Virtio Interfaces
There are three components to having a working virtio interface. They are:
A specification, preferably documented in the upstream OASIS VIRTIO specification
A device driver, usually in an OS kernel like Linux*
this is sometimes referred to as a front-end
A device implementation
this is sometimes referred to as a back-end
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.
Who is working on the interface?
Interface | Worked on by? | Cuttlefish, Android Studio Emulator | Comments |
|---|---|---|---|
virtio-block |
| critical | used for all storage volumes. |
virtio-fs |
| debug | used for file sharing between host and guest - we use the fuse+dax version, not the older 9p version. |
virtio-console |
| critical | used for logcat, kernel logging, serial console, other HAL services with simple protocols. |
virtio-RPMB | Linaro | no interest | PoC C daemon |
virtio-SPI |
| early interest | part of the virtio-greybus |
vsock |
| critical | this is used for experiments and anything without a proper virtio interface, but we are trying to reduce use of it. However used widely for a number of container+VM solutions |
virtio-rng |
| critical | needed to run on some processors without good RNG instructions. critical. Stratos rust-vmm backend |
virtio-pmem |
| critical | used for Restore-On-Reboot in Android R. We also hope to move Android 'pstore' to use it, but it needs work. |
virtio-net |
| critical | used for mobile data, wireless and ethernet connectivity. |
virtio-input |
| optional UX interactions only. | used for touchscreen, keyboard, multi-touch support (being added to crosvm upstream right now). |
virtio-SCMI | Linaro, | no interest | Linaro PoC with Zephyr backend in QEMU |
virtio-balloon |
| no plans to use | deprecated by virtio-pmem |
virtio-tpm |
| no plans to use |
|
virtio-scmi |
| no interest |
|
virtio-wl |
| no plans to use |
|
virtio-camera |
| early interest |
|
virtio-mac80211 |
| considering | cuttlefish comment or a new "virtio-wifi" - we need a more feature-rich virtio backend for wifi. Currently we stack virt_wifi (upstreamed driver from Google) on top of virtio_net to provide nl80211 to Android, but we need features like P2P, AP mode, wifi transfer. We have just started to explore this. |
virtio-snd | OpenSynergy | considering | this was pushed upstream by OpenSynergy and is being used by COQOS. We are adding support for it to crosvm right now, and hope to use it soon. |
virtio-vdec | Chrome | considering | this was pushed upstream by Chrome and is being used by ARC-VM. It enables offload of video decoding to the host. Currently, we don't support that feature, but we want to explore it for Android. |
virtio-can |
|
| second priority because controlled by a safe OS. |
virtio-tuner |
|
|
|
virtio-i2c | Linaro | early interest | part of the virtio-greybus |
virtio-Wayland | google? |
|
|
virtio-video |
|
| What does it include. C based PoC but so far no spec upstreamed |
virtio-vehicle |
|
|
|
virtio-radio |
|
|
|
virtio-argo |
|
| high security transport |
virtio-gpio |
| early interest |
|
virtio-gpu |
| optional | This is interesting to LDCG for AI purposes cuttlefish are running an experimental version with "blob" support. optional, without it we can use SwiftShader and render in software to shared memory |
virtio-watchdog | Linaro (LEDGE and LDCG) | interested for debug |
|
virtio-greybus | Linaro should do. Not sure whom yet | early interest | encompasses i2c, SPI and GPIO |
trustzone / TPM virtio interface |
|
| will need investigation |
vmm control of CPUs not under the control for the hypervisor |
|
|
|
Specification exists
Interface | Specification | Comment |
|---|---|---|
virtio-RPMB | 1.2 | PoC C daemon, needs Linux driver upstreaming |
virtio-SPI |
|
|
virtio-SCMI | 1.2 |
|
virtio-camera |
| out of tree PoC by Collabora |
virtio-can |
|
|
virtio-tuner |
|
|
virtio-i2c | 1.2 |
|
virtio-wayland |
| out-of-tree, possible extension to carry over virtio-gpu |
virtio-video |
|
|
virtio-vehicle |
|
|
virtio-radio |
|
|
virtio-net | 1.2 | neet investigation by LDCG to determine suitability for use cases |
Block/SCSI | 1.2 |
|
Console | 1.2 |
|
Entropy | 1.2 |
|
Memory balloon | 1.2 |
|
GPU 2d/3d | 1.2 |
|
Input | 1.2 |
|
Crypto | 1.2 |
|
Socket | 1.2 |
|
FS | 1.2 |
|
IOMMU | 1.2 |
|
Snd | 1.2 |
|
Memory | 1.2 |
|
virtio-gpio | 1.2 |
|