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.


Next Meeting

(green star) Tuesday, July 24, 10:00 AM CET

Agenda:

  • Zoom Meeting details:

Backlog (Topic List)

  • (ongoing) GENIVI Tech Summit, plans for content
  • (ongoing) HV API standards / virtual platform definition.
  • (ongoing) Concrete use-case, architectures and requirements
  • (new) More was added to the AGL publication on virtualization.  Re-review, to identify useful/reusable parts.
  • (future) Albert, planning presentation (TBC)

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

  • API for virtualized device drivers: VirtIO
  • API for security: MAC
  • 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

  • Reference implementation: based on which hypervisor(s)? 
    • → All are welcome.  Company provided development input will in practice affect this.

Minutes & other info

Project Pages


Munich AMM Workshop Agenda

Virtual Device standardization

Common I/O devices for hypervisor guests with standardized features and interface, such that device drivers (and thereby systems) are more portable.

Advantages:

  • 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

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

Resources and Links

Related publications and input

Videos/recordings

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


  • No labels