This contains just some minutes.  Main project page here.

June 5

Agenda:

• getting everybody updated
• review of critical use cases.

Participants:

• Albert Kos (Conti)
• Kai Lampka (EB)
• Christoph Lipka (ADIT)
• Franz Walkembach (Sysgo)
• Sriram (KPIT)
• Sang bum Suh (Perseus)
• Gunnar (GENIVI)
• Philippe (GENIVI)

apologies: Matti (Opensynergy)

Minutes

• getting everybody updated: we have currently 3 threads active
  • device driver virtualization (prepared by Matti)
  • AGL paper review (prepared by Nikola)
  • critical use cases (prepared by Sriram)
• device driver virtualization
  • Matti cannot attend today's call, got the clearance to provide his inputs, will upload them in the wiki today, topic for next week
• critical use cases
  • Sriram presents the critical use cases wiki page and his views on how APIs can be identified allocated in an instrument cluster context
  • Sriram: this is WIP, will add block diagrams
  • Sriram: details the assumptions and the use cases
  • Gunnar: we need to check how these use cases fit with the domain interacti
• more on use case / scenario #1 - Rear view Camera at Startup
  
  • Sriram: the rear view camera can be Ethernet connected, or LVDS connected, rather than analog cameras (converted to digital)
  • you still need to compose the camera output with the park assistant
  • it is a data stream available on a certain port
  • Ethernet  based cameras would be a good use case to start with
• discussion
  
  • Sang-bum: AGL paper talks about resource allocation on top of hypervisors (linux VM, Android VM)
  • Albert: we need to make a distinction between various partitions (safe, secure, others), it is a very complex landscape, IMHO that cannot be solved with one HV, first of all we have to focus on the safety critical part (Autosar based) based on type 1 HV and look at type 2 HV for other applications (e.g. linux containers, etc.)
  • Gunnar: we are not at this step of describing a solution using type 1 and/or type 2
  • Sang bum: we need to make a decision on our scope type 1 only and/or upper layers with sw virtualization
  • /TODO/ Albert provide a problem statement for next week (for instance on the rear view camera)
  • Kai: IMHO in order to be concrete with safety, we need to address ASIL levels which is a far-reaching goal, we should first focus on requirements like boot time and data throughput and latency bounds which current HV technologies have problem to comply with
  • Kai: most OEMS are a bit hesitating because they are not convinced HV will meet performance requirements
  • Sang bum: what about VMs on top of an HV ?
  • Kai: first need is to run legacy code and to have different sw islands to run them
  • Sang bum: IMHO para-virtualization is included in the scope of solutions
  • Sang bum: state of the art is that silicon supports virtualization, we do not need para-virtualization
  • Sang bum: in GENIVI we could runLMbench on linux on top of HVs and make performance measurements
  • discussion on performance benchmarking (for audio for instance)
  • Gunnar: this benchmarking is an industry effort, would start this by having this group agree on the method to do the measures
  • Albert: not sure, we did this benchmarking already
  • Sriram: I will add KPI to the use cases I have provided, we need to treat each problem statement, we have the right group to do the job
  • Sang bum: Android ? running on the fly of Android applications  is another use case, using this approach OEMs could avoid Google certification
  • Gunnar: asks every participant to provide his views in the wiki
  • /TODO/ All provide inputs on the various problem statements in the wiki page
• next week
  • review of Opensynergy inputs on virtual device drivers

May 29

Agenda:

• review of the summary of AGL paper prepared by Nikola .

Participants:

• Nikola Velinov (GHS)
• Sriram Gopalan (KPIT)
• Christoph Lipka (ADIT)
• Philippe (GENIVI)
• Gunnar (GENIVI)
• Sang-Bum Suh (Perseus)

Minutes

review of the summary of AGL paper prepared by Nikola
summary is short, everybody invited to read it
sections 3, 5 & 6 are the most relevant for HV project
section 3 can be adopted as a set of reference use cases
discussion on how we (as a GENIVI project) can build on the inputs from the AGL paper
Certain chapter should be reusable as they are, others with some modification.  Some chapters ahave useful content which should be quite widely applicable (multiple Linux, Yocto-based systems etc.) but the text cannot be used as-is since it uses a lot of specific language referring to "the AGL system", and similar expressions.

next week

• more feedback from other participants who did not attend today's call
• Opensynergy inputs on virtual device drivers (if internal go was given)

May 22

Participants:

• Kai Lampka (Elektrobit)
• Gayathri PP (Tata Elxsi)
• Matti Möll (OpenSynergy)
• Nikola Velinov (GHS)
• Sriram Gopalan (KPIT)
• Philippe (GENIVI)
• Gunnar (GENIVI)

Apologies

• Sang-Bum Suh (Perseus)

Minutes

API standardization
Matti started writing down thoughts.  Needs some approval on content

Matti introducing:

• Definition of the virtual platform...
• virtio as specified, and/or looking at defacto implementations e.g. in Linux 
• there are feature flags in the virtio spec - define which ones should be mandatory for automotive use case
• Then guests can be developed against this virtual platform – possible to run guest on any HV that fulfils the platform
  
  
• It's like "Virtual appliances"  used to be a popular concept.  Now containers/applications-containers, same principle.
  • Package certain software as a machine image. Deploy to cloud.
  • Before virtualization "appliance" is a box of where the software is running, then virtual-appl.
• This work in GENIVI could specify such a baseline environment that describes the set of devices.
• Can be done by referencing existing standards. 
• Agreeing on the subset of features that automotive requires - what is mandatory instead of optional.
• Example:  The discard capability of the block device. Is optional in virtio, but for embedded, this should be mandatory.
• Discard = Hinting to a flash device that something is not being used anymore.

Discussion:

• Nikola: Virtio standardizes a restricted set of devices only, e.g. GPU(?), what about the devices that are still in draft status.
• Matti: One option is to drive the virtio standards forward (to fill those gaps)
  ... the other is to just say we shall be compatible with current implementation (in Linux)
• Nikola: agrees with Matti's proposal
• Nikola: I'm interested in how to ensure compatibility/compliance to what we define.
• Gunnar: Driving virtio from draft to specific ("work upstream"), specify gaps, and promote that we support a particular defacto defintion.  All of those activities help drive standards forward.
• Matti: Plugfests is an option, such as has been done for Bluetooth. (for ensuring compatibility, and also driving standards forward)
• Kai: How much functionality should go into (virtio) driver vs (low-level) device driver part.
• Kai: How to handle non-open implementations (hardware specific low-level driver) etc?
• Matti: VirtIO should abstract those details typically. We should help to define that.
• Kai: HVs allow for Central device driver management which is useful, it can enforce certain policies. 
• Matti: I agree.  Example: block-write rate limiting
• Sriram: What about Type 1 vs Type 2. For example using KVM, having a full Linux kernel can be very useful. Type 2 approach enables more possibilities that bare metal 
  implementation. Also look at Xen. Why don't we look at those.  Maybe also go back to requirements first.
• Gunnar: All of those technologies are also represented in our group, (and some might even consider themselves to be their own type). [Thin layer HV and RTOS based, etc.]
  Virtual Open Systems work on KVM for example, and others are strong on Xen.  I don't right now see a reason to limit to one type. 
• Several: Requirements can help clarify what is needed.
• Gunnar: I think we should drive those things forward also. I called it a separate workstream but I don't want to create boundaries. I think these things are very related. The only thing is, we won't stop one track (API standards) that we already started, in order to go back to the foundation. I think we can progress this in parallel now.
• Sriram: I have some use cases I'm thinking about, I could write them down.

Additional thoughts from participants.

Wrapping up

Action Items

• Nikola study and summarize AGL whitepaper, in particular looking for basis for defining "the virtual platform", and of course requirements, use-cases, etc.  Use Wiki page to summarize.
• Sriram - Write down cases / concrete architecture examples / specific challenge (such as, audio startup&latency in a particular architecture)

May 15

No posted minutes

May 8

Minutes

Discussion on – see the title Device Standardization on main page: Hypervisor Project

Sang-Bum:  Hypervisors need to include a mandatory access control features
Matti: But in theory guests can run without ever speaking to a hypervisor.
Matti: It is difficult to standardize APIs to speak to the hypervisor itself - easier to standardize device driver layer.

Sang-Bum: We need to add a security architecture to control (negative) impact from one guest to another.  We need MAC support APIs to achieve that.

Matti: I would like to start the standardization topic by writing down a proposal.l

April 19
(Full-day All Member Meeting Workshop)

Please see the Hypervisor Workshop Schedule at Munich AMM page for schedule, speakers, participants and meeting minutes.

April 10 

Further preparations of AMM agenda

April 3

Participants

• Ajmal  (Tata Elxsi)
• Artem Mygaiev (EPAM)
• Gayathri PP (Tata Elxsi)
• Ralph Sasse (Opensynergy)
• Guru (Bosch)
• Christian (BMW)
• Nikola (Green Hills Software)
• Franz (Sysgo)
• Gunnar Andersson (GENIVI)
• Philippe Robin (GENIVI)
  
  

Apologies

• Sang-bum Suh (Perseus)

Minutes

• Notice / presentation of new participants:  Nikola (Green Hills Software).  And previous participants now with opportunity to present themselves:  Ajmal and Gayathri PP (TataElxsi) 
• Continuation of the assignment of topics preparation with the participants, the topics and assignments for the workshop are listed under Hypervisor Project.

March 27

Participants

• Ajmal  (Tata Elxsi)
• Alex Agizim (EPAM)
• Artem Mygaiev (EPAM)
• Gayathri PP (Tata Elxsi)
• Horst Saier (Mentor)
• Matti Möll (OpenSynergy)
• Raj
• Sean Park (LGE)
• jithin (Tata Elxsi) ?
• Subramanian (Alpine)
• Stephen Lawrence (Renesas)
• Gunnar Andersson (GENIVI)
• Philippe Robin (GENIVI)
  
  

Apologies

• Sang-bum Suh (Perseus)

Minutes

• Gunnar tried to get contact with TataElxsi participants but still no audio coming through (microphone not working)
• Continuation of the assignment of topics preparation with the participants, the topics and assignments for the workshop are listed under Hypervisor Project.

March 20

Participants

Philippe Robin (GENIVI)
Sang-bum Suh (Perseus)
Matti Möll (Opensynergy)
jithin (TataElxsi)
Gunnar Andersson (GENIVI)
Christian Schulenberg (BMW)
Subramanian (Alpine)
Gayathri PP (Tata Elxsi)
Stephen Lawrence (Renesas)
Ajmal  (Tata Elxsi)

Minutes

• Gunnar tried to get contact with TataElxsi participants but still no audio coming through (microphone not working).
• Gunnar reviewed the assignment of topics preparation with the participants, the topics and first assignments for the workshop are listed under Hypervisor Project.

March 12 

Participants
Philippe Robin (GENIVI)
Gunnar Andersson (GENIVI)
Sang-bum Suh (Perseus)
Christian Schulenberg (BMW)
Horst Saier (Mentor)
Subramanian (Alpine)
Guru (Bosch)

Minutes

Gunnar highlighted some of the topics for the workshop listed under Hypervisor Project.

Sang bum: introduced the workshop to LGe, Hyundai and Access in the recently hold Korea REG F2F, would like to collect their opinion so that we can share at the workshop
trying to contact xen so that they give a presentation at the workshop on their automotive projects, intends to contact redhat with is leading virtio
Sang bum: contact with car oem and tiers 1, my personal opinion is they do not know yet what it is the exact case to usefully apply HVs to a vehicle, in the process of trying to convince car OEMs to deliver market scenarios, coins the idea of sending a questionnaire to car oems
Sang bum will share an initial questionnaire with us at the next meeting (20 March)
Horst: my interest lies rather in graphics sharing
Gunnar:graphics will be one of the topics of the workshop
Horst: how to share graphic buffers, is a solution available in the open ? it is currently very silicon vendor dependent
Gunnar: Horst Saier can you a short intro in the workshop about it ?
Gunnar: @sang bum: are you familiar with gpu sharing ?
Sang bum: yes, I am very familiar, the problem is that silicon vendors except Intel do not publish the code of the drivers for gpu sharing
short discussion on audio virtualization
Sang-bum: would like to discuss device driver architecture at the workshop
Sang-bum: will propose a list of topics for Wed 14 March EOB
Christian: we are very interested in the market survey and what is available from vendors

March 6

Participants

• Guru (Bosch)
• Albert (Continental)
• Christoph (ADIT)
• Christian (BMW)
• Gunnar (GENIVI)
• ... maybe someone else - not sure

Minutes

We simply discussed and filled in the topics under Hypervisor Project.  Discussion much driven by Albert and Christoph.

February 27

Participants

• Albert / Continental
• C. Gouma / Sysgo
• Fabien H / Valeo
• Gayathri PP
• George
• Karthikeyan R
• Marco R / Mentor
• Matti Möll / Opensynergy
• Philippe / GENIVI
• sbsuh
• Stephen L / Renesas
• Swaminathan G
• Gunnar / GENIVI

Minutes

• Introductions
  • Gunnar tried to get contact with Ajmal, Gayathri, Karthikeyan, George, and some others but no answer.
    • Apparently there were microphone troubles all around
• Purpose/idea and organization history of Hypervisor initiative
  • Seoul AMM activities October 2017
  • Discussion & Preparing
  • "Do it right" - i.e. start only when/if significant interest
  • New developments – new lead (Sang-Bum)
  • Workshop at AMM  lots of interest - time to start planning agenda
• Started the topic list under Hypervisor Project - minutes & other
• Requirements need - OEMs usually don't give HV related requirements - they are more functional.
• Could we create some kind of (shared) Baseline requirements for HV vendors?
• (Sysgo): I do not believe in any kind of open source solution...
  
  • ... to solve Level 2 [or higher] autonomous driving... 
  • ... the code base is too big
• Gunnar: ... making a note that code base size is independent of code license
• (someone): We need to know which devices are important (for OEMs) 
• (someone): We expect safety requirements to be provided
• Albert:
  • Need to listen to the voice of customers
  • case studies
  • safety issues
  • 26262  - many are not familiar
  • difference in needs between IVI (not safety critical) vs cluster (is safety critical)
• accelerate towards (some kind of) safety approval
• HV solutions have been deployed (to solve this) not only in automotive - in aviation at least 5 years ago