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
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
- 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
- HV design and implementation
- 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
- 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
- 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 driv
- Device drivers (for paravirtualization) for the (Linux*) kernel don't need to be maintained uniquely for different hypervisors
*virtio supported by BSD, Windows, Fuchsia, and others
vi
Related introduction from OpenSynergy at All Member Meeting, Seoul, 2017. –> see PDF presentation