Page tree

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: More Prelimnary chapters


3. Common Virtual Device categories

3.1 Storage (Block Device)

 When using hypervisor technology data on storage devices needs to adhere to high-level security and safety requirements such as isolation and access restrictions. Virtio and its layer for block devices provides the infrastructure for sharing block devices and establish isolation of storage spaces. This is because, actual device access can be controlled by the hypervisor. However, Virtio favors generality over using hardware-specific features. This is problematic in case of specific requirements w.r.t. robustness and endurance measures often associated with the use of persistent data storage such as flash devices. In this context one can spot three relevant scenarios:


  Comments on the above, according to previous discussions

3.2 Network Device

Standard networks

Standard networks means those that are overwhelmingly standard in the computing world.  In other words, any IP based network, typically with TCP (UDP for certain cases) as transport.  While it's not really necessary to put limits on that, the physical layer is normally some variation of the Ethernet standard(s) or WiFi, or other transport that transparently exposes a TCP/IP network interface.

(warning) PLACEHOLDER:  It is assumed that [VIRTIO] specification is an adequate definition of how to describe virtual platform interface and that operating systems can easily expose physical, virtual and inter-vm networks as network interfaces, i.e. what in Linux might be listed for a physical interface with a name like "eth0".

  • Virtual and hardware (pass-through) interfaces shall be exposed as the operating system's standard network interface concept.
  • The hypervisor/equivalent shall provide the ability to dedicate and expose any hardware network interface to one virtual machine.
  • The hypervisor/equivalent shall(?) be able to configure virtual inter-vm networking interfaces. (question)

Communication between VM and hypervisor.   This is described as vsock in the VIRTIO specification.  (warning) Is there a use case for this?

Automotive networks

All traditional in-car networks and buses, such as CAN, FlexRay, LIN, etc., which are not Ethernet TCP/IP style networks, are treated in the chapter TBD.

Time-sensitive Networking standards

(warning) Placeholder.  How do those requirements affect, and how is the real-time demands implemented in practice in a virtual environment?

3.3 GPU Device

The virtio-gpu is a virtio based graphics adapter. It can operate in 2D mode and in 3D (virgl) mode. The device architecture is based around the concept of resources private to the host, the guest must DMA transfer into these resources. This is a design requirement in order to interface with 3D rendering.


                     a. The device MUST set reserved and reserved1 to zero.
                     b. The device MUST set undefined flags to zero.
                     c. The device MUST write a valid endpoint ID in endpoint.
                     d. If a buffer is too small to contain the fault report (this would happen for example if the device implements a more recent version of this specification than the driver, whose fault report contains additional fields) , the device SHALL NOT use multiple buffers to describe it. The device MUST fall back to using an older fault report format that fits in the buffer.



Special Virtual Device categories

4.x Automotive Sensors

Protocol access

Sensors can be handled by a dedicated co-processor or the hypervisor implementation and provide the sensor data through a communication protocol.  This essentially offloads the burden of defining a "virtual hardware access" from the VM to the measuring hardware.   

Systems Control Management Interface (SCMI) protocol was not originally defined for the virtual-sensor purpose itself, but describes a flexible and an appropriate abstraction for sensors. It is also appropriate for controlling power-management and related things.  The actual hardware access implementation is according to ARM offloaded to a "Systems Control Processor" but this is a virtual concept.  It could be a dedicated core in some cases, perhaps in others not.

  • The hypervisor/equivalent shall use SCMI protocol to expose sensor data from a dedicated sensor subsystem to the virtual machines.

Direct Hardware access

For sensor hardware that shall be processed directly by the operating system it may be necessary to provide physical or virtual hardware access

  • The hypervisor/equivalent shall provide configurable pass-through access to a VM for sensor hardware ((warning)which category of hardware?)
  • The hypervisor/equivalent shall be 

For digital I/O pins, refer to standard pinmux specification ((warning) need clarification)


4.x Audio

4.x Media codec 

TODO Hardware-assisted codecs

4.x Cryptography

(warning) TBC No particular info in VIRTIO on this?

4.x.x Random Number Generation

Random number generation is typically created by a combination of a true-random and pseudo-random implementations.  A pseudo-random generation algorithm is implemented in software.   "True" random values may be acquired by a hardware-assisted device, or a hardware (noise) device may be used to acquire a random seed which is then further used by a pseudo-random algorithm.

  • The virtual platform SHALL provide VMs with access to a hardware-assisted high quality random number generator through the operating system's preferred interface. 
    (/dev/random device on Linux)
  • (warning) TODO, improve this:
    The virtual platform should describe a security analysis of how to avoid any type of side-band analysis of the random number generation.

5. Supplemental Virtual Device categories

5.x  Text Console

While they may be rarely an appropriate interface for the normal operation of the automotive system, text consoles are expected to be present for development purposes.

(warning) TBC.  It is expected that the virtual interface of the console is adequately defined by [VIRTIO].

  • To not impede efficient development, text consoles shall be according to the operating systems' normal standards so that they can be connected to any normal development flow.
  • Text consoles are often connected to a shell capable of running commmands.  For security reasons, text consoles shall be possible to shut off entirely in the configuration of a production system.  This configuration must furthermore not be modifiable from any guest operating system.

5.1 9pfs and host-to-vm filesystem sharing