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

Purpose and Rationale

The Hypervisor Project follows after two successful workshops at the last two GENIVI All-Member-Meetings and 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 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.

You can look below for detailed backlog and topics, but to summarize there are two primary work streams currently in development:

  1. Virtual Device API standardization, leading to the definition of the Automotive standard Virtual Platform
    (this builds on existing standards like VIRTIO naturally)

  2. Investigate and recommend electrical/software architecture for automotive use-cases, when deployed using virtual-machine technologies. 

Next Meeting

(green star) Tuesday, January 15, 10:00 AM CET

Agenda (preliminary)

Backlog (Topic List)

  • Memory Buffer sharing (GPU) - invite Eugen Friedrich
  • Milestones, deliverables, and workplan.
  • (started) Concrete use-case, architectures and requirements
  • 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.

Mailing list & Contribution

Currently we use the general genivi-projects mailing list. (warning) Start the subject line using: [HVWS]

Please contribute/improve the Wiki.  Improve text, add relate info, links, references!  To edit the Wiki, log in or request an account.

Any process question? - you can contact the current project lead, currently:  Gunnar Andersson

Sub-topics, with possible dedicated meetings (for prioritization)

  • API for security: Mandatory Access Control features (in virtualization)
  • 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,
  • Terms / Nomenclature

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).

Meeting Minutes (← use link)

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

Common I/O devices for hypervisor guests with standardized features and interface, such that device drivers (and thereby systems) are 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
  • Some potential for shared device driver implementation across hypervisors

*virtio 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

Resources and Links

Related publications and input


  • Platform Security Summit May 23-24, 2018 - had several hypervisor related presentations – Youtube, (website

 Munich AMM Workshop Agenda (2018 April) (← use link)

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

  • No labels