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:
Virtual Device API standardization, leading to the definition of the Automotive standard Virtual Platform
(this naturally builds on existing standards like VIRTIO)
- Investigate and recommend electrical/software architecture for automotive use-cases, when deployed using virtual-machine technologies.
Tuesday, March 12, 11:00 AM CET (! NOTE DIFFERENT TIME !)
- AMM plan and attendance (confirmation)
- ARM presentation on SBSA - Server Based System Architecture
- The SBSA covers ideas on organizing access to various hardware features.
- ARM has offered to the HV working group participants a detailed paper on SBSA (on request, and with signed NDA)
- During this session we will get a public overview delivered by an expert from ARM.
- We made the association to SBSA during a discussion of virtualization of Watchdog features, but there are other areas that it may also influence.
- Reference links, virtual platform definition: (Topics intro and table summary here) (draft spec work here)
- Zoom Meeting details:
Meeting Minutes (← use link)
Most Active Workstream:
- Definition of Automotive Virtual Platform (a.k.a. API standardization for Hypervisors in automotive environment, with starting point in VIRTIO)
Backlog (Topic List)
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.
Original sub-topics (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
Mailing list & Contribution
- Discussion should use the general genivi-projects mailing list. Start the subject line using: [HVWS]
- 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.
- Any other process question? - you can contact the acting project lead: Gunnar Andersson
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
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.
Other resources and Links
Related publications and input
Samsung Resarch - Automotive Virtualization, presented at Xen Summit 2018.
- VIRTIO v1.0 specification (and newer git master?) – first start for our investigation into the definition of an Automotive-Wide virtualization platform
- The AGL software defined connected car architecture (a.k.a "AGL virtualization paper")
- PDF (snapshot May 2018) ^^^ NOTE that is an older snapshot of a living paper, (Google Docs edit location).
- Paper analysis/summary written by Nikola Velinov with intro paragraph by Gunnar Andersson – based on May 2018 snapshot.
- UPDATE:→ Study this latest published version (June 2018) from AGL publication page
- Platform Security Summit May 23-24, 2018 - had several hypervisor related presentations – Youtube, (website)
Bangalore Technical Summit Agenda (2018 October) (← use link)
Munich AMM Workshop Agenda (2018 April) (← use link)
( ^^ includes links to many topic presentations by the participants)