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

Compare with Current View Page History

« Previous Version 10 Next »

Automotive Virtual Platform Specification

1. Introduction

Automotive requirements lead to particular choices and needs from the underlying software stack.  Existing standards for device drivers in virtualization need to be augmented because they are often not focused on automotive or even embedded, systems.  Much of the progression comes from the IT/server consolidation and in the Linux world, some come from virtualization of workstation/desktop systems.

A collection of virtual device driver APIs constitute the defined interface between virtual machines and the virtualization layer, i.e. the hypervisor or virtualization "host system".  Together they make up a definition of a virtual platform.  

This has a number of advantages:

  • Device drivers (for paravirtualization) for the kernel (Linux in particular), don't need to be maintained uniquely for different hypervisors
  • Simplify moving hypervisor guests between different hypervisor environments
  • Some potential for shared implementation across guest operating systems
  • Some potential for shared implementation across hypervisors with different license models
  • Industry shared requirements and test-suites, a common vocabulary and understanding to reduce complexity of virtualization. 

In comparison, the OCI initiative for containers serves a similar purpose.  There are many compatible container runtimes → there could be the potential for standardized "hypervisor runtime environments" that allow a standards compliant virtual (guest) machine to run with less integration efforts.

  • Hypervisors can fulfill the specification, with local optimizations / advantages
  • Similarly, guests VMs can be engineered to match the specification.

2. Architecture

Assumptions made about the architecture, use-cases...

Limits to applicability, etc...


3. General requirements

Automotive requirements to be met (general)...

3. Common Virtual Device categories

3.1 Block Device

3.1.1 Standard Serial Device

(lightbulb) REQ-1:   Requirement according to chapter x.y in [VIRTIO].


3.2 Network Device

...


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.


3.3.1 GPU Device in 2D Mode

In the unaccelerated 2D mode there is no support for DMA transfers from resources, just to them. Resources are initially simple 2D resources, consisting of a width, height and format along with an identifier. The guest must then attach backing store to the resources in order for DMA transfers to work.

        Device ID.

(lightbulb) REQ-1:   The device ID MUST be set according to the requirement in chapter 5.7.1 in [VIRTIO-GPU].

Virtqueues.

(lightbulb) REQ-2:   The virtqueues MUST be set up according to the requirement in chapter 5.7.2 in [VIRTIO-GPU].

Feature bits.

(lightbulb) REQ-3:   The VIRTIO_GPU_F_VIRGL flag, described in chapter 5.7.3 in [VIRTIO-GPU], SHALL NOT be set.

        Device configuration layout.

(lightbulb) REQ-4:   The implementation MUST use the device configuration layout according to chapter 5.7.4 in [VIRTIO-GPU].

(lightbulb)      REQ-4.1: The implementation SHALL NOT touch the reserved structure field as it is used for the 3D mode.

        Device Operation.

(lightbulb) REQ-5:   The implementation MUST suport the device operation conceprt (the command set and the operation flow) according to chapter 5.7.6 in [VIRTIO-GPU].

(lightbulb)      REQ-5.1: The implementation MUST support scatter-gather operations to fulfil the requirement in chapter 5.7.6.1 in [VIRTIO-GPU].

(lightbulb)      REQ-5.2: The implementation MUST be capable  to perform DMA operations to client's attached resources to fulfil the requirement in chapter 5.7.6.1 in [VIRTIO-GPU].


        VGA Compatibility.

(lightbulb) REQ-6:   VGA compatibility, as described in chapter 5.7.7 in [VIRTIO-GPU], is optional.


3.3.2 GPU Device in 3D Mode

3D mode will offload rendering ops to the host gpu and therefore requires a gpu with 3D support on the host machine. The guest side requires additional software in order to convert OpenGL commands to the raw graphics stack state (Gallium state) and channel them through virtio-gpu to the host. Currently the 'mesa' library is used for this purpose. The backend then receives the raw graphics stack state and interprets it using the virglrenderer library from the raw state into an OpenGL form, which can be executed as entirely normal OpenGL on the host machine. The host also translates shaders from the TGSI format used by Gallium into the GLSL format used by OpenGL.


        Device ID.

(lightbulb) REQ-1:   The device ID MUST be set according to the requirement in chapter 5.7.1 in [VIRTIO-GPU].


Virtqueues.

(lightbulb) REQ-2:   The virtqueues MUST be set up according to the requirement in chapter 5.7.2 in [VIRTIO-GPU].

        Feature bits.

(lightbulb) REQ-3:   The  implementation MUST set the VIRTIO_GPU_F_VIRGL flag, described in chapter 5.7.3 in [VIRTIO-GPU].

        Device configuration layout.

(lightbulb) REQ-4:   The implementation MUST use the device configuration layout according to chapter 5.7.4 in [VIRTIO-GPU].

(lightbulb)      REQ-4.1: The implementation MUST use the previously reserved config structure field to report the number of capsets supported by the virglrenderer library.

(lightbulb)           REQ-4.1.1: The implementation SHALL NOT report the value of '0' as it is treated as absence of 3D support. 

        Device Operation.

(lightbulb) REQ-5:   The implementation MUST suport the device operation conceprt (the command set and the operation flow) according to chapter 5.7.6 in [VIRTIO-GPU].

(lightbulb)      REQ-5.1: The implementation MUST support scatter-gather operations to fulfil the requirement in chapter 5.7.6.1 in [VIRTIO-GPU].

(lightbulb)      REQ-5.2: The implementation MUST support the extended command set as described in chapter 'Virtio-GPU | Virgl3D commands' in [VIRTIO-VIRGL].

(lightbulb)      REQ-5.3: The implementation MUST support the 3D command set as described in chapter 'VIRTIO_GPU_CMD_SUBMIT_3D' in [VIRTIO-VIRGL].

(lightbulb)      REQ-5.4: The implementation MUST support the VIRTIO_GPU_CMD_GET_CAPSET_INFO command set as described in [??? only kernel sources as a reference so far].

(lightbulb)      REQ-5.5: The implementation MUST support the VIRTIO_GPU_CMD_GET_CAPSET command set as described in [??? only kernel sources as a reference so far].

(lightbulb)      REQ-5.6: The implementation MUST be capable  to perform DMA operations to and from client's attached resources to fulfil the requirement in chapter 5.7.6.1 in [VIRTIO-GPU] and in 'Virtio-GPU | Virgl3D commands' in [VIRTIO-VIRGL].


        VGA Compatibility.

(lightbulb) REQ-6:   VGA compatibility, as described in chapter 5.7.7 in [VIRTIO-GPU], is optional.

Additional features.


(lightbulb) REQ-7:  In addition to the command set and features, defined in [VIRTIO-GPU] and [VIRTIO-VIRGL], the implementation MAY provide:

    • an additional flag to request more detailded GL error reporting to the client


3.4 IOMMU Device

NOTE: The current specification draft looks quite neat except the fact that it marks many requirements as SHOULD or MAY and leaves it for an implementation. Here I try to provide more strict rules when it is applicable.

(lightbulb) REQ-1:   Requirement according to chapter 2.1 in [VIRTIO-IOMMU].

(lightbulb) REQ-2:   Requirement according to chapter 2.2 in [VIRTIO-IOMMU].

(lightbulb) REQ-3:   Requirement according to chapter 2.3 in [VIRTIO-IOMMU].

(lightbulb) REQ-4:   Requirement according to chapter 2.4 in [VIRTIO-IOMMU].

(lightbulb) REQ-5:   Requirement according to chapter 2.5 in [VIRTIO-IOMMU].

(lightbulb)      REQ-5.1: As for chapter 2.5.2, the requirement is to be read as SHALL NOT.

(lightbulb) REQ-6:   Requirement according to chapter 2.6 in [VIRTIO-IOMMU].

(lightbulb)      REQ-6.1: As for chapter 2.6.2, MAY and SHOULD are to be read as MUST, SHOULD NOT is to be read as SHALL NOT.

        (lightbulb)      REQ-6.2: As for chapter 2.6.3.2, SHOULD is to be read as MUST, SHOULD NOT is to be read as SHALL NOT.

        (lightbulb)      REQ-6.3: As for chapter 2.6.4.2, SHOULD is to be read as MUST, SHOULD NOT is to be read as SHALL NOT.

        (lightbulb)      REQ-6.4: As for chapter 2.6.5.2 SHOULD is to be read as MUST, SHOULD NOT is to be read as SHALL NOT.

        (lightbulb)      REQ-6.5: As for chapter 2.6.6.2 SHOULD is to be read as MUST, SHOULD NOT is to be read as SHALL NOT.

        (lightbulb)      REQ-6.6: As for chapter 2.6.7.2 MAY and SHOULD are to be read as MUST, SHOULD NOT is to be read as SHALL NOT.

        (lightbulb)      REQ-6.7: As for chapter 2.6.8.2.2 SHOULD is to be read as MUST, SHOULD NOT is to be read as SHALL NOT.

        (lightbulb)      REQ-6.8: As for chapter 2.6.9.2 SHOULD is to be read as MUST, SHOULD NOT is to be read as SHALL NOT.

4. Supplemental Virtual Device categories

4.1 9pfs and host-to-vm filesystem sharing

    <insert results about where to use and our conclusion that it has little applicability in automotive>


3. References

    [VIRTIO]  Virtual I/O Device (VIRTIO) Version 1.0, Committee Specification 04, release 03 March 2016.

    [VIRTIO-GPU]  Virtual I/O Device (VIRTIO) Version 1.0, Committee Specification 03-virtio-gpu, release 02 August 2015.

    [VIRTIO-VIRGL]  [AN OASIS STANDARD PROPOSAL OR OWN PAPER IS NEEDED]  https://github.com/Keenuts/virtio-gpu-documentation/blob/master/src/virtio-gpu.md


    [VIRTIO-IOMMU]  VIRTIO-IOMMU DRAFT 0.8




  • No labels