The Automotive Virtualization 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.
| Status | ||||
|---|---|---|---|---|
|
- The virtual platform definition would allow the development of virtual machine guests that like appliances in the enterprise world, could be moved among different hypervisor systems without (minimal) modification.
| Status | ||||
|---|---|---|---|---|
|
A clear and detailed specification is required to achieve true portability, and to give real support to vendors.
Hand-waving about some virtual architecture is not our goal. The specification shall enable efficient reuse and collaborative progress among companies in this industry.
| Status | ||||
|---|---|---|---|---|
|
Specifications like these are best developed as open specifications and just like open-source code, it should stand on the shoulders of previous work. Lots of existing standards should be built upon where VIRTIO is the most prominent we have found. However as this field progresses it is clear that the automotive industry should (will) one way or another make sure that combine into commonality.
The project group has discussed and found consensus on how that automotive specification should be done:
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.
In the work done here (see table below) we categorize device types and ensure that each need has been thoroughly analyzed so that as an industry we can truly define the right specification, to be applicable in >95% of the typical situations.
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
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)
...
- VIRTIO v1.0 specification. VIRTIO is the starting point for our investigation into the definition of an Automotive-Wide virtualization platform
- Version 1.1 is under development - therefore we should make sure to study the latest proposals – see git master
Evaluation Process for existing specifications (e.g. VIRTIO)
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)not yet listed (e.g. unique automotive requirements)
Note also: Bottom of this page has a "brainstorm" list of criteria to consider.
...
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:
...
- Availability?
- Is there a proposal for standard (specification)?
- Is it accepted in VIRTIO?
- Is it a de-facto standard?
- Implementation status
- ...In QEMU/Linux kernel?
- ...FOSS in a GitHub Repo?
- ...Commercial/closed-source implementations?
- ... 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? Are the technical requirements hindering implementing it efficiently, for some reason? Does it matter?
- Code Maturity?
-- ...implementation dependent, but evaluate that which exists
- Evaluate: Security aspects
- Evaluate: Functional Safety aspects
...