Published Documents
AVPS Specification, version 2.0 (PDF)
Want to know more?
Look at parent page and follow the references from the main project page.
...
Next Version (work in progress)
The official working location is <new online version to be created> to enable collaborative editing.
Feel free to read the latest, but please engage with the project before proposing changes directly in the document.
Older versions
AVPS Specification, version 1-01 (PDF)
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.
- Some potential for shared device driver implementation also across non-Linux operating systems
- Ability to move hypervisor guests between different hypervisor environments
- Potential for shared understanding, requirements and test-suites for different implementations of the virtual platform.
- Some potential for shared device driver implementation across hypervisors with different license models
In comparison, the OCI initiatives for containers serves a similar purpose. There are many compatible container runtimes → can we have standardized "hypervisor runtime environment" that allows a standards compliant virtual (guest) machine to run.
- Hypervisors can fulfil the specification (with local optimizations / advantages)
- Similarly, this specification is what guests can be engineered to.
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
REQ-1: Requirement according to chapter x.y in [VIRTIO].
3.2 Network Device
...
3.3 GPU Device
3.3.1 GPU Device in 2D Mode
REQ-1: Requirement according to chapter 5.7.1 in [VIRTIO-GPU].
REQ-2: Requirement according to chapter 5.7.2 in [VIRTIO-GPU].
REQ-3: The VIRTIO_GPU_F_VIRGL flag, described in chapter 5.7.3 in [VIRTIO-GPU], SHALL NOT be set.
REQ-4: Requirement according to chapter 5.7.4 in [VIRTIO-GPU].
REQ-4.1: The implementation SHALL NOT touch the reserved structure field as it is used for the 3D mode.
REQ-5: Requirement according to chapter 5.7.6 in [VIRTIO-GPU].
REQ-5.1: The implementation MUST support scatter-gather operations to fulfil the requirement in chapter 5.7.6.1 in [VIRTIO-GPU].
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].
REQ-6: Requirement, described in chapter 5.7.7 in [VIRTIO-GPU], is optional.
3.3.2 GPU Device in 3D Mode
REQ-1: Requirement according to chapter 5.7.1 in [VIRTIO-GPU].
REQ-2: Requirement according to chapter 5.7.2 in [VIRTIO-GPU].
REQ-3: The implementation MUST set the VIRTIO_GPU_F_VIRGL flag, described in chapter 5.7.3 in [VIRTIO-GPU].
REQ-4: Requirement according to chapter 5.7.4 in [VIRTIO-GPU].
REQ-4.1: The implementation MUST use the previously reserved config structure field to report the number of capsets supported by the virglrenderer library.
REQ-4.1.1: The implementation SHALL NOT report the value of '0' as it is treated is absence of 3D support.
REQ-5: Requirement according to chapter 5.7.6 in [VIRTIO-GPU].
REQ-5.1: The implementation MUST support scatter-gather operations to fulfil the requirement in chapter 5.7.6.1 in [VIRTIO-GPU].
REQ-5.2: The implementation MUST support the extended command set as described in chapter 'Virtio-GPU | Virgl3D commands' in [VIRTIO-VIRGL].
REQ-5.3: The implementation MUST support the 3D command set as described in chapter 'VIRTIO_GPU_CMD_SUBMIT_3D' in [VIRTIO-VIRGL].
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].
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].
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].
REQ-6: Requirement, described in chapter 5.7.7 in [VIRTIO-GPU], is optional.
REQ-7: In addition to 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
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.
...