Hypervisor Workshop Team

Organizing of the Domain-interaction Hypervisor project, with inititial focus on the full-day AMM Workshop.

Next Meeting

NOTE: Tuesday, May 1 – skipped due to bank holiday in several countries

Tuesday, May 8, 10:00 AM CET

Agenda:

Sub-topic definitions
- API standardization
- Reports and educational material

Zoom Meeting details:

- Registration link (if you do it before, it saves time)
- Join link
- Meeting password: hvws

Topic Introduction

Informative and teaching everyone to a similar level of understanding
Technical neutral information, no sales pitch
Try to open questions for discussion
Define what is the remaining problem
- Technology needs improvement?
- Uncertainties?
- Information/documentation/lacking understanding?
- ....
Suggestion:
- Final slide could be a list of questions (to the workshop participants)

AMM Workshop Agenda (Topic name & Responsible)

This is a workshop session spanning several hours. We expect significant participation from all attendees. Each topic should have a short introduction (maximum 10 minutes) followed by interactive discussion. Individual topics should be introduced by a variety of Hypervisor vendors and other experts, such as OpenSynergy and Perseus.

Discussion topics will include:

Workshop introduction and intention
- Introduced by: Gunnar (GENIVI), Sang-Bum (Perseus)
History of HVs
- Introduced by: Sang-Bum
Introduction to XEN project
- by: Lars (Xen) (TBC by Sang-bum)
Market Overview
- by:Franz Walkembach (SysGo)
  - includes an intro to certification
Requirements gathering
- HV vendors asking OEMs/adopters/customers/etc to clarify technical requirements
- Introduced by: Matti (Open Synergy)
Performance comparison between open source software based hypervisors on ARM SoC
- Introduced by: Sang-Bum
HV design and implementation
- Introduced by: Ralph (Open Synergy)
- useful link: Opensynergy presentation in Seoul
Virtualization for Multi-core, SoC peripheral hardware and special-purpose CPUs
- Introduced by:Artem (EPAM) + input on Samsung roadmap (Sang bum)
Standardization of hypervisor APIs (virtio and friends)
- Introduced by: Open Synergy (virtio intro + what's needed?) + ?
How can reliability & safety be quantified?
- Introduced by:
- - how to invite experts? TUV/similar?
Audio system design with HVs
- Introduced by: Artem (EPAM)
- Discussing GENIVI AudioManager extensions
Graphics/GPU Sharing (in relation to GSHA project)
- possibly show-and-tell multiple vendors?
- Introduced by: - reaching out to Renesas ?
Health/Debugging/Analysis/Logging (in relation to SHDA project)
- Introduced by:
(Cyber-)Security enhancements based on virtualization
- Introduced by: Sang-Bum
System design and working with HVs from users/system integrator's perspective.
- Introduced by:
- ? tier-1 or OEM leading discussion?
- Hardware integration. Communication issues between vendors?

AMM Workshop Agenda Topics (brainstorm and more details)

Requirements gathering
- Requests from HV vendors for OEMs/adopters/customers/etc to clarify technical requirements,
  e.g. on particular driver, performance, reliability, safety.
  - Central device driver management?
    - ^^ Lead/intro by Sang-Bum
    - i.e. HV+BSP supporting hardware register access arbitration.
    - ...?
    - Even possible without this? What would be design patterns to use if the HV is not giving the hardware virtualization you need.
  - BSPs available vs. needed
  - Unikernel support
    - e.g. tested/demonstrated
    - any special matching needed between HV and unikernel (para-virtualization) – likely not...
- (Maybe in particular, how is reliability & safety quantified?)
  Boils down to: Several safety related parts brought together - how to design (and evaluate) the total system.
- Footprint
  - Memory usage
  - # Lines of code (auditing/reliability/trust...)
Training / informative materials?
- Vendor-independent
- From users/system integrator's perspective.
- What can be done today, what can't be done today
- Consequences of para virt or hardware support for virtualization, and related BSP design
  - Related introduction from OpenSynergy at All Member Meeting, Seoul, 2017. –> see PDF presentation
- Connection between "management/sales" slides and the very detailed HV documentation. Knowledge required in the gap here.
Cross-domain architectures, examples, recommendations
- (repeated from above) Boils down to: Several safety related parts brought together - how to design (and evaluate) the total system.
- (repeated from above) Consequences of para virt or hardware support for virtualization, and related BSP design
  - Is design even possible without virtualized hardware? Design patterns to coordinate access if the HV is not giving the hardware virtualization you need?
- 12 factors for service-oriented platforms.
Required technology demonstrations
Market/Technology survey
Requirements survey - Questionnaire (to OEMs)
- Results could be statistics/anonymized if needed.
- Start work on this questions list.
Feature evaluation
- Compare features
  - Separate BSPs - paravirt or hardware virt support?
- ... or simply list "what types of features can a Hypervisor have"
- Comparing types of HV / key characteristics?
Graphics/GPU Sharing (in relation to GSHA project)
- What things are hardware dependent?
- How to share graphics buffers?
Health/Debugging/Analysis/Logging (in relation to SHDA project
Audio...
- Past approaches are known and can be discussed (Sang-Bum)
  - e.g. paravirt devices
  - audio mixing in operating system can handle it instead of paravirtualized drivers
  - Complete architecture idea, e.g. with GENIVI AudioManager
  - One hardware run Cluster
How to minimize impact on the development process when using HVs
Glossary/terms - does everyone have the same understanding of terms?

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.

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)

Automotive Hypervisor Compatibility Definition

Collect from different sources.
AGL paper can be starting point

Page tree