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

Minutes & other info

Munich AMM Workshop Agenda

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

• Introduction to project 

Automotive Hypervisor Compatibility Definition

• Collect from different sources.
• AGL paper can be starting point