Page tree
Skip to end of metadata
Go to start of metadata

Purpose and Rationale

The Hypervisor Project is producing a common open licensed Automotive Standard Virtual Platform specification based on VIRTIO, and other standards.

On the more general scope, the project investigates the wide scope of open- source and commercial hypervisor technologies, and addresses challenges in their use.

Through collaboration between all vendors, experts and adopters of virtualization technology we can lower the barriers to successful product development.

The project primarily drives requirements, standardization for Hypervisor APIs, and other types of investigations to facilitate ECU consolidation, price reduction, and management of mixed-criticality in systems for improved security and functional safety.

There are three primary work streams currently in development:

  1. Virtual Device API standardization, leading to the definition of the Automotive standard Virtual Platform
    collecting and driving requirements for a standard platform based on VIRTIO, SCMI, and other existing standards.

  2. Multi-OS system design on Multi-Core SoCs (with/without virtualisation)
  3. Investigate and recommend electrical/software architecture for automotive use-cases, when deployed using virtual-machine technologies. 

Next Meeting

Every Monday, 10:00 AM CET


  • Working towards V2 release including updates in Graphics, IOMMU, Media/cameras and other.

General backlog

  • MCU virtualization (Renesas offered to give more information)
  • eAVB/TSN (consider what use cases impact HV, perhaps master control of network, and what AVB/TSN features support guest seperation) [added after discussion in 22/2/21 call)
  • AVPS v2 work --> JIRA tickets 
    • Media & Cameras - finalize discussion?
    • Follow up on IOMMU discussion from 2 weeks ago.
    • A few other topics that need update
  • Check progress on whitepaper
  • Work on next release of platform definition
  • Look at active sprint & backlog of HV tracker
  • Review / check consensus on USB chapter of specification + other minor edits (Artem to come back with new info)
  • AI/Tensor processing, on GPU or other dedicated hardware
  • Deep-dive Memory Buffer sharing (GPU) - invite Eugen Friedrich
  • Update Milestones, deliverables, and workplan.
  • (started, needs input again) Use-cases, architectures and requirements workstream
  • Some was added to the AGL publication on virtualization after our most recent review.  Re-review, to identify useful/reusable parts.  Links at the bottom.

Zoom Meeting details:

Meeting Minutes (← use link)



  Related publications and input

Mailing list & Contribution

  1. Discussion should use the general genivi-projects mailing list(warning) Start the subject line using: [HVWS]
  2. The Wiki is an open public collaboration area.  Please contribute/improve it as needed.  Improve text, add relate info, links, references! 
    To edit the Wiki, log in or request an account.
  3. Any other process question? - you can contact the acting project lead:  Gunnar Andersson

Upcoming Events / F2F

GENIVI 20th All Member Meeting a Digital Experience

F2F Meetings (completed)

Original topic-list (possible focus areas)

  • APIs for security: Mandatory Access Control features (in virtualization environments, that is)
  • VM management tool
  • Instrumentation & tools
  • Safety compliance: ISO26262
  • Security compliance: Common Criteria, EAL
  • System design to optimize Boot Time,
  • Boot requirements, e.g. secure boot, integrity check,
  • Agree on Terms / Nomenclature

Done / skipped / no longer on backlog

  • Reactions to Samsung presentation 

  • Reference implementation: Should be based on which hypervisor(s)? 
    • → Answer:  All are welcome.  The companies that do the development will in practice affect the choice(s).

Project Pages summary

Topic Introduction:
Virtual Device standardization, a.k.a. Automotive Virtual Platform definition

Define common I/O devices for hypervisor guests with standardized features and interface, such that device drivers (and as a consequences systems, virtual-machines) become more portable.


  • Device drivers (for paravirtualization) for the (Linux*) kernel don't need to be maintained uniquely for different hypervisors
  • Ability to move hypervisor guests between different hypervisor environments
  • Definite potential for shared experience and getting the right functionality into the APIs.  
    • Heterogeneous cross-system testing will strengthen specs and implementation.
  • Some potential for shared device driver implementation across hypervisors (dependent on licenses - open-source, closed-source)

*virtio also supported by BSD, Windows, Fuchsia, and others

Extending this: Standardizing a contract/standard between guest and hypervisor.  Compare the OCI initiatives for containers.  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.

Compare: Linux Device Tree – ability to discover and configure devices.

The work is documented here

  ((green star) ^^ includes links to many topic presentations by the participants)

  • No labels