It was over a year ago that the first version of the Automotive Virtual Platform Specification (AVPS) was released, and during the pandemic year the AVPS has made slow but steady progress, leading to a new release.
The contributors to this specification are now proud to present version 2.0. This version carries significant updates in many critical chapters including Graphics, IOMMU, cryptography features, and introduces some new device areas as well.
The AVPS v2.0 is around 50 pages long and keeps its original style of including both a Discussion section and a formal Requirements section for each topic:
The discussion sections make up the bulk of the text so that the requirements can be succinct. Because of the complexity of the subject matter and the fast moving state-of-the-art, the discussion sections provide an overview of the current situation and important context for the requirements. This is not so common for requirement specifications, but seems very useful in this case. That introduction to each topic clarifies the rationale for the requirements and can also be a starting point for any discussions among buyers/users and providers/sellers of virtualization technology. The requirement section is the normative part and the document includes a specific chapter about what it means to follow / be compliant with, the specification. Regarding the content, the overwhelming industry standard for kernel-to-hypervisor APIs (virtual device APIs) is VIRTIO. For that reason the AVPS requires the use of VIRTIO in many areas, by referring to specific parts of the VIRTIO specification rather than repeating or rewriting those requirements.
AVPS serves a purpose in addition to the existing VIRTIO specification document as follows:
- AVPS selects and specifies which parts of the full VIRTIO specification (some of which is applicable to servers and desktops) are applicable in an automotive environment. We think it is important that the automotive industry takes charge of its own destiny when it comes to virtualization technologies, and define what it means to have an automotive virtual platform.
- In addition to virtual device APIs that are covered by VIRTIO, AVPS adds platform requirements outside of the device API. As an example, the boot-protocol defines how operating systems in Virtual Machines (VM) are booted on a virtual platform and is very important for VM portability across implementations. The AVPS is similarly a place where other automotive-specific requirements can be collected, including non-functional requirements (such as performance or other characteristics).
- For features that do not fit into the VIRTIO specification or are not planned to be covered, the AVPS is a place to define another solution and for areas that are not yet completed in VIRTIO, an alternative stopgap solution could be written. In some cases the AVPS is already requiring VIRTIO-related proposals that have been generally agreed, but not yet released into a versioned VIRTIO document.
- Finally, in certain specific areas, automotive products might not be able to avoid specific solutions, such as hardware-specific support. In certain cases, the only reasonable choice is one that might not match any proposed generic abstraction API. Graphics is currently one such example where using hardware-assisted features is desired and unavoidable. To be truly useful, and not simply circumvented, an industry-specific requirement specification like AVPS must take into account the design choices that are most likely in automotive products. This means writing reasonable, tailored requirements. In certain selected areas these may include compromises to better reflect the reality of the industry.
The team is proud of the achievement of getting version 2.0 out the door, and it is time to again spread the word of its existence and welcome further additional community input! The AVPS document has an open-source (Creative Commons) license which is a guarantee for your time investment.
In combination with VIRTIO, the automotive industry industry now has a strong starting point for a shared virtualization standard, and additional input can increase its scope and quality even further. Join the work to improve this important area of automotive technology!
– Gunnar Andersson - Technical Lead, GENIVI Alliance