You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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 of that architecture used,
several 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 efficiently possible 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

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.

  • No labels