About VIRTIO
The VIRTIO standard aims to provide a standardized interface and device models for device para-virtualization in hypervisor environments.
With development going back until 20XX the virtio device model was first introduced for the educational "lguest" hypervisor and became the default I/O virtulaization method used with qemu/KVM and recently the default model used by many cloud providers. The virtio devices have been partially standardized by the OASIS standardisation body in 2015 with the VIRTIO 1.0 specification which describes the transport layer and a limited set of device models.
The currently standardized device models are: network, block, console, entropy, memory ballooning and SCSI devices. Additionally to the formally standardized devices several additional devices exists as "implemented" devices such as GPU, input, 9pfs, vsock and crypto. Some of which are currently in the process of standardization.
Virtio relies on a dma-like memory model meaning that all allocations are handled by the "driver" part of the device and the "device" implementation can directly access the allocated buffers for reading or writing. This enables a resource saving and fast operating mode. Metadata is transported using so called virt-queues that resemble ring-buffers. Depending on the architecture used, different transport and device discovery modes are supported: PCI for x86, mmio for ARM and channel-IO for s390. These transports are geared toward the most efficient implementation per CPU architecture and allow for efficient implementations depending on the environment.
In recent years some hardware devices, like network controllers and NVMe based storage systems have evolved to be similar or compatible with the VIRTIO protocol, to allow hardware assisted I/O virtualization using para-virtualized device models.
VIRTIO Benefits
VIRTIO's main benefit for the automotive industry lies in it's sheer existence and operating system support. The fact that standardized device models exists allows for multiple compatible implementations of both driver and server parts of the system. The ubiquity of VIRTIO in cloud and enterprise virtualization makes drivers readily available in all major operating systems which keeps driver maintenance effort to a minimum.
Due to the driver defined memory allocation model, vendors can choose to limit the resource usage and define safety properties to their own requirements without impeding the standardized model and stay interoperable with existing device implementations.
The DMA-like nature of the devices allows for high-performant implementations that the easily compete with hardware assisted I/O virtualization models while still providing relative ease of implementation.
Many vendors of automotive grade hypervisors have already adopted virtio based devices into their system offerings due to the above mentioned reasons and the benefit of building upon these open source technologies has greatly improved the availability of commodity devices like network and block storage.
The Virtualized Platform
To allow further success of hypervisor environments in automotive it is essential that all vendors are able to provide compelling guest runtime environments that make the usual automotive I/O devices available. The essential devices could be defined and agreed upon by the industry.
If such a set of devices and device features is defined a document can be crafted that defines these devices and their features that in their combination create a virtual platform.
A virtual platform would allow the development of virtual machine guests that like appliances in the enterprise world, could be moved among different hypervisor systems without further modification.
For such a virtualized platform virtio is primarily a starting point because the defined devices enable running only basic system functionality but lack the multimedia and other devices often found in automotive environments.
Instead of developing additional domain or even vendor specific device frameworks and models a collaborative development could greatly reduce the individual development of project efforts and thus spur the adoption of hypervisor based environments in the automotive sector.
Additional efforts definitely need to be spent in the area of audio virtualization and the in virtualization of co-processors like DSPs, image processors and codec accelerators. Developing a standard model for the diverse buses found in cars like CAN or ethernet AVB could also be additional fields of investigation.
GENIVI and AGLs Role
(Opensynergy's proposal)
Vendor neutral industry bodies like GENVI and AGL can act a forum between hypervisor vendors, users and the hardware manufactures in a form that allows open collaboration in development and maintaining a standard platform definition.
The regular events can be used as occasions for interoperability testing and standard steering. The participation in the OASIS-VIRTIO committee can be delegated to such organization to voice the automotive industries concerns and advice in the technical committee.
GENIVI has in the past maintained domain specific APIs and standards can easily act as a body that makes sure the standard is not only maintained but also advanced as new technologies evolve.
AGL can provide the necessary collaboration with the upstream kernel project and the Linux Foundation which in-turn opens up for collaboration with the key industry players in cloud and enterprise computing.
Evaluation Process
For each topic:
- Discuss and write down the automotive requirements
- Read VIRTIO chapter
- Decide if VIRTIO is appropriate and complete for requirements (Gap Analysis)
- Write down what the industry needs to do to close the gap
Consider topics not yet listed (e.g. unique automotive requirements)
Virtual Device Categories
The key challenge for defining a shared virtual platform definition is to first identify the various device driver types such a platform must provide, and to evaluate if existing work so far (e.g. VIRTIO) covers what the automotive industry needs:
| (Virtual) Device | Explanation | Champion | Completeness / Applicability evaluation
| Comments and discussion |
|---|---|---|---|---|
| Block Storage | Flash/Disk/persistent storage | Kai | ||
| Network | Access to (shared) physical ethernet and guest-to-guest communication | Nikola | ||
| Console | Text terminal input | Gunnar |  WIP | Done initial browsing of the specification. Opinions still pending. |
| crypto | Access to cryptographic services (hardware accelerated) | Sang-bum | ||
| GPU | Graphics hardware | Matti/Dmitry | ||
| Input | Traditionally keyboard/mouse/etc - for automotive = expanded? | Matti | ||
| vsock | Communication between guest (VM) and host (hypervisor) | |||
| 9pfs | 9P = protocol to expose host (hypervisor) file systems to the guest. FS=filesystem. | Gunnar | Use-cases: ? Completeness: Protocol: Need in Embedded/Automotive: Applicability: |
Essentially used for "shared folder" capability between host & guest, as in desktop (or maybe some server) usage. Its applicability to embedded hypervisor usage, in which the "host" is not really being used by itself) seems questionable. What's the use-case? In VIRTIO spec: A PCI type device can indicate that it is going to use the 9P protocol. The specification also has 9P as a specific separate device type. Other than that, I found no further description of such a device type. The protocol is specified elsewhere and complemented by scattered information regarding the specific implementations (Xen, KVM, QEMU, ...) The protocol seems proven and supposedly OK for what it does. Possibly more security features needed, depending on use-case. VIRTIO however seems to defer the definition completely to "somewhere else"? At least a reference to a canonical specification would seem appropriate. Overall it is a minimalistic network file-system protocol. It seems apt for the task. Understandably, other network protocols like NFS, SMB/SAMBA etc. would have been too heavy. It feels a bit esoteric, and while "reinventing" is bad, in this simple case would not be the worst ever, if VIRTIO had defined something else. Flexibility and security features seem somewhat glossed over. There's basically only "fixed user" or "pass-through" for mapping ownership on files in guest/host. |
| vIOMMU | IOMMU coordinates of DMA devices' | Dmitry | ||
| Audio | Matti | |||
| Sensors | Automotive sensors: | Automotive sensors? Radar/LiDAR/? (or are they separate ECUs?) Standard embedded sensor (ambient light...) Some OS have requirements - eg. Android requires orientation sensor. | ||
| Media Acceleration (VPUP, IPU, CODEC) | Hardware support for codec/processing Abstraction of SoC specifics DSPs Tensor processors | VPU = "AI" CPU optimized for visual recognition | ||
| USB | Franz | |||
Other Serial devices? (Where does LIN, etc. fit in?) | ||||
| CAN | Franz | virtio-can: VIRTIO-based CAN driver | ||
| Ethernet (incl. AvB/TSN) | Nikola | |||
| Bluetooth | Sang-bum +OpenSynergy with BT experience | Is it possible? Needed? | ||
| Memory Balloon Device | Applicable? |
VIRTIO-defined devices
The VIRTIO 1.0 specification is organized a bit differently, and more generic than our detailed list above. Here is a much abbreviated table of contents for VIRTIO 1.0, just to give an overview on the most important parts. Consider, especially, the limited types of devices. All defined devices are under these categories only for the 1.0 version.
2 Basic Facilities of a Virtio Device
2.4 Virtqueues
3.1 Device Initialization
3.2 Device Operation
3.3 Device Cleanup
4 Virtio Transport Options
4.1 Virtio Over PCI Bus
4.2 Virtio Over MMIO
4.3 Virtio Over Channel I/O
5 Device Types
5.1 Network Device
5.2 Block Device
5.3 Console Device
5.4 Entropy Device
5.5 Traditional Memory Balloon Device
5.6 SCSI Host Device
7 Conformance
7.2 Driver Conformance
7.3 Device Conformance
7.4 Legacy Interface: Transitional Device and Transitional Driver Conformance
B Creating New Device Types
Criteria:
- Availability?
- Is it accepted in VIRTIO?
- Is there a proposal for standard (specification)?
- Is it a de-facto standard?
- Implementation status
- In QEMU/Linux kernel?
- FOSSS in a GitHub Repo
- Commercial/closed-source implementation
- Number of implementations?
-
- Complexity estimation?
-- e.g. CAN Device class, vs GPU (need to consider large User-space
library, complex HALs,
-
- Performance?
-- mostly implementation dependent
- Code Maturity?
-- implementation dependent
Importance for automotive use-case
- n
- Mainly applicable for all-use cases or for a specialized use-case