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
Tuesday, July 17, 10:00 AM CET
Agenda:
- Reactions to Samsung Paper (linked below under General Publication)
- New list of group topics - sort and prioritize.
- Discuss opportunity for multiple meets per week (on sub-projects / sub-topics).
- API standardization / virtual platform definition
- Action for all: Look at list of devices (bottom). Start evaluating: Responsible person, Is VIRTIO adequate, What are the automotive requirements, ...
- Milestones, deliverables, and workplan.
- AOB
- Zoom Meeting details:
- Registration link (if you do it before, it saves time)
- Join link
- Meeting password: hvws
Backlog (Topic List)
- (ongoing) GENIVI Tech Summit, plans for content
- (ongoing) HV API standards
- (ongoing) Concrete use-case, architectures and requirements
- (future) Albert, planning presentation (TBC)
Sub-project candidates list (for prioritization)
- API for virtualized device drivers: VirtIO
- API for security: MAC
- VM management tool
- Reference implementation: which hypervisor will be based?
- 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
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.
General Publications
- Samsung Resarch - Automotive Virtualization, presented at Xen Summit 2018.
Automotive Hypervisor Compatibility Definition
- Collect from different sources.
- The AGL software defined connected car architecture (a.k.a "AGL virtualization paper")
- PDF (snapshot) ^^^ NOTE that is a snapshot of a living paper, (see Google Docs edit location).
- Paper analysis/summary written by Nikola Velinov with intro paragraph by Gunnar Andersson
Project Planning
TODO:
- Introduction to project, current status and what needs to be done
- Break down into actions
- Resourcing - clarify group participation & time spent (roughly)