Hypervisor Project - minutes

 This contains just some minutes.  Main project page here.

August 14, 2018

Participants:

• Nikola (GHS)
• George Dunlap (Xen Project)
• Lars Kurth (Xen Project)
• Bernhard Rill (ARM)
• Artem (EPAM)
• Christoph (ADIT)
• Gunnar (GENIVI)
• Sriram (KPIT), second half of meeting
  
  

Apologies:

• Philippe, Sang-Bum, ...others

Agenda:

• Device standards / VIRTIO continued
• Bangalore tech summit

Minutes

Gunnar: Let's Re-introduce the VIRTIO/Device Driver/Virtual Platform definition project because of new/returning participants.

The intention is to write a virtual platform definition that can encompass the whole Automotive Industry.  So, supporting Linux & non-Linux operating systems (according to Industry
wishes). It would ideally support hypervisors developed with FOSS licenses and other models.

VIRTIO has been proposed as starting point. We're now evaluating each device type / topic:

- What is defined by VIRTIO
- What are the automotive Requirements
- Evaluate applicability and completeness. Clarify the gap.

Gunnar: First study has been on VIRTIO 1.0 but I have seen that there is
additional work ongoing. There is a git master...
Lars: Yes, a version 1.1 is planned. You should make sure to cover the
latest.
Gunnar: Agreed, action taken to steer our evalution towards git-repo master - if that's what is most appropriate?
Lars: I assume that's it, but I or George, could look into that.

George shares various experience from Xen project:
...VIRTIO was designed with KVM in mind first
...also for Xen we have found this to be a problem in some areas
...For example, it is assumed that QEMU (which provides the VIRTIO implementation when using KVM) has full access to all of the guest memory all the time.
...it is stated that VIRTIO devices bypass IOMMU completely.

George: In Xen we want to build features that do not match this, such as VM having control over which backends can write into its memory. We have a concept of Driver Domains, which adds security. A layer of security in case of bugs/vulnerability in implementation. For example something like a network card driver may be run in its own VM, with a well defined communication interface to the client VMs that use it.

Lars: Should we write down driver isolation as an automotive requirement?

Bernhard: Also, looking at the list of general considerations, please make sure to add Functional Safety

Artem: ... and Security

Artem: I see comments about implementation dependent things. Isn't the goal for GENIVI to implement standard implementations [that can be used by multiple parties?]

Gunnar: (paraphrased): Yes, this is a likely goal but it remains to be seen how this project progresses. We start with analyzing and defining requirements and specification. However, a specification needs implementation to prove
viability. This is GENIVI's experience since the beginning. Previous compliance programs, have always required _some_ software to prove for example an API specification is appropriate, before it becomes part of the specification.

Gunnar: For this project we have received input from, for example Green Hills, that [even independent of the question of porting VMs across different HVs], at implementation and quality maintenance of drivers is a
significant effort. So it seems many, including commercial HV vendors would benefit from more shared implementations too if it's feasible.

Nikola: Agreed. We will have to see [how much implementation can be shared] - such as... how much work is required to make VIRTIO implementation have high enough performance?

Bernard Rill: Have you [Xen Project] evaluated portability across architectures? ... I mean SW layers etc.

[ Discussion to understand how/if such standards are easy or hard to implement in diverse software. ]

Nikola: I would also agree. It is clear that VIRTIO came from a non-embedded starting point. Therefore need to figure out if it can be transformed towards better supporting embedded.

(... also some answer from Xen Project)

Gunnar: Interesting and important - please share such experiences by documenting/linking in the Wiki. We need to collect evidence and information to see the full picture. But I would like to steer the conversation back from "is this possible" more towards actually doing the required work now. (looking at table again)

Gunnar: Please volunteer for the topics that have no Champion yet.

Artem: Looking at Sensors... Aren't most sensors just providing an interface using some standard device class, such as serial? They rarely provide any particular HW support, so it's surely para-virt. So it is more
about defining a protocol. We have in fact defined some protocols, as part of XenPV work.

Gunnar: That might very well be the conclusion. Seems you have done half the work now  - can you add these thoughts to the Wiki, and then we check consensus later? I'll put your name down on Sensors

Artem is assigned to Sensors. He also volunteers EPAM for media acceleration topic.

... Also what about "data-intensive devices". Fast DMA/memory implementation.

Gunnar: I don't know. I guess the IOMMU topic will branch out into a wide discussion (It's all about memory handling).

Lars: I can't volunteer me or George at this time - need to check availability.

Lars: I saw no info about mailing list...

Gunnar: At current we use genivi-projects.  Butt we can set up a dedicated list.  What would be the group desire - to have a smaller list for intense discussion in the core group?   Because I thin to keep others informed, it would just be yet another list for them to subscribe to.

Lars: Genivi-projects should be OK.  It won't be too high volume.

Gunnar: OK, I will add clearer info to project page.

Lars: We might be interested in smaller focused meetings around some topics, bringing together for example Matti, George and perhaps Stefano.
Gunnar: No problem, we just arrange the meeting time for particular meetings.
Lars: OK, I will use the mailing list.

Lars: I think (VIRTIO) v1.1 has a deadline close to end of the year. We should check the window of opportunity to affect it.

Sriram: I have joined. I will study the Wiki page and VIRTIO specifications.

Lars: ...will be busy for the next 3 weeks or so. Open Source Summit and other things.

Summary of meeting and housekeeping.
Meeting adjourned.

August 7, 2018

Cancelled due to vacations

July 31, 2018

• Matt Spencer
• Bernhard Rill
• Kai Lampka
• Christian Schulenberg
• Stephen Lawrence
• Philippe
  

Agenda:

• preparation of the technical summit in Bangalore - 9-10 October

• Focus will be on HV project and Graphics Sharing project

• We intend to have a HV project readout on Day 1 afternoon (duration: 1h30) and a working session on Day 2 (duration: half-day). There will be a networking event on Day 1 evening.

• We need a critical mass of attendees already involved in the HV project to have a productive working session

• We would like to check who intends to attend the event (either personnally or through one of your colleagues based in India or elsewhere) and gather topics for discussion for the working session.

• there will be no big showcase at the technical summit (next big showcase will be at CES 2019), some demos might be shown though at the technical summit upon request
• Main topics for the working session will
  • device drivers standardization: it is important to make sure the virtio community is aware of the work done by GENIVI, for the next two weeks, it is expected that assignees (in the table at the bottom of API standardization / virtual platform definition
    will add description of device drivers, then starting mid-August, the HV project should start discussing how to coordinate with upstream projects (please look at Opensynergy presentation at ALS in June)
  • automotive use cases: for the time being we have been only through one use case (rear view camera), analysing a second use case should be at the agenda of the HV project after mid-August so that some results might be shown and discussed at the technical summit
    • TODO @Sriram any feedback on this ?
• in addition, participants are welcome to propose topics / problems to solve that could be debated at the working session
• next call is scheduled on Tuesday 14 August

July 24, 2018

• Frank

• Gunnar

• Matti

• Sang-bum

• Philippe
  

Agenda:

• API standardization / virtual platform definition 
  
  • Action for all: Look at list of devices (bottom). Continuation of allocation of device drivers description to participants

  • discussion on criteria

    • Matti: more detailed criteria for applicability of device drivers to automotive are needed, we need to formalize the criteria

    • Matti: the idea for FUSE came from 9pfs, FUSE is a modern linux version of a pseudo file system like 9pfs, it is a very interesting technology

    • Matti: one criterion is : is it standardized already ? is it implemented ?

      • example: CAN device driver is implemented but not standartized yet

    • another criterion is complexity (i.e. complexity estimate of the device implementation: for CAN all you need is a kernel implementing the CAN device class

• next two weeks will be dedicated tof filling the wiki page API standardization / virtual platform definition with content

July 17, 2018

• Frank

• Nikola

• Kai

• Philippe

• Gunnar

• Ralph

• Sang-bum
  
  

• Sriram Gopalan
• ...

Minutes

• Additional discussion about Virtual Platform Definition
• Kai has previously been "assigned as a volunteer"  for block storage.  And it was confirmed.
• Kai: Can we write down more than one person, a team of interested people?
• Gunnar: We can add more, but in my experience we need a topic lead to move things forward.  The lead can of course be involved in "recruiting" more people also...
  
• Gunnar asked Nikola, who selected Network devices & Ethernet (+AVB)
• Gunnar asked Frank, who accepted to look into USB - will discuss with other SysGo engineers.
• Gunnar asked Ralph.... Ralph will ask Matti to select some topics.
• Gunnar asked Sang-bum to cover some topic(s) based on his experience.  Sang-bum does not have time right now to evaluate a topic.
  
• Everyone needs to do the evaluation of their selected topic
  1. Write down / figure out the automotive requirements
  2. Read VIRTIO chapter
  3. Decide if VIRTIO is appropriate and complete for requirements (Gap Analysis)
  4. Write down steps to close any gap
• Action(All):  Assign yourself as "lead" for 1-2 topics and write it on the page.  Then perform the steps above.

July 03, 2018

Participants:

• Christoph Lipka
• Guru R
• Sang bum Suh
• Sriram 
• Nikola 
• Gunnar
• Philippe

Agenda

• *technical summit*, 10-11 October, Bangalore, India
• Milestones, deliverables, and workplan.
• API standardization – VIRTIO intro!

June 26, 2018

Participants:

• Christoph
• Sang bum
• Sriram
• Nikola
• Gunnar
• Philippe

Minutes

• Discussion on boot times...
  • Just for reference: 1 second Linux Boot example (old) (not snapshot or hibernation, if I recall correctly)
    "Real-world" might be different.
• Sang-Bum: <100ms hypervisor load is generally possible.  What is the requirement?
• /TODO/ Add Sriram's notes
• architecture proposed by Sriram at the bottom of this page  is aligned with the rear camera use case
• discussion on EVS (External Video System) on top of android
• discussion on Green Hills solution
• /TODO/ Nikola upload the diagram with a micro-kernel based RTOS architecture (with HV as a thin layer on top of RTOS)
• RTOS is responsible for the scheduling, HV is there to enable Linux
• Nikola: goto GHS website the GHS solution is fully described there
• Nikola; you do not need to boot the whole linux to get the rearview camera up & running, you need to boot only the rtos part
• Sang bum; would you require two video streams, one coming from rtos and the later another one coming form android or linux ?
• discussion on the handover of video streams

Sriram's notes - minor edits and formatting

(Camera use-case an architecture)

• Birds Eye View / Surround View could be possibly only implemented in the Android Partition and may not be available as part of early RVC
• Following are options for supporting such a use case through out the lifetime of a IVI session ( from startup to shutdown)
  • Everything in Vehicle domain ( Basic as well as advanced view ) => No handover / arbitration required with any other domain
  • Basic implementation in Vehicle domain + Advanced implementation in Linux/Android domain => Handover / arbitration of camera stream is required
  • Everything in Linux/Android domain ( Basic as well as advanced ) =>
  • Dedicated partition ( potentially a third domain besides Vehicle and Android/Linux domain) that does everything
• What are the implications for Hypervisor? 
  • Constraint as of today in Android : Cannot do early RVC within 2 seconds.. however that is on the roadmap
  • Linux does not have this constraint as it is completely Open Architecture and free from Compability aspects 
• Solutions for early camera systems
  • Snapshot / Hibernation speeds up boot and production solutions with < 2 seconds camera is possible
  • Example from a camera product( high end camera )
  • No safety aspects in consideration in the above example; non-automotive
• Load time of hypervisor ~ 100 ms

June 19, 2018

Agenda:

• VIRTIO intro
• Use Case → Architecture → Problem Statement → Results

Participants:

• Nikola
• Sriram
• Subramanian
• Christoph
• Gunnar
• ...

Apologies:

• Sang-Bum
• Matti
• Horst

Minutes

• The need for a shared vocabulary again
• Nikola: API standards like VIRTIO should apply to Type1/Type2 equally
  • Link VIRTIO 1.0
• Is libvirt implementation a useful addition to the plain specification? - is it really widely used? 
• Discussing project scope & results
  • ...
• Plan: Discuss use case per meeting
• Discussing rear-view camera case once more
  • E.g. long-booting kernel require another solution for camera
  • Common solution:  Bootloader → early-boot program runs camera → later on there is some type of hand-over
  • Gunnar: As discussed last week, a small core (on SoC) usually handle the wake-up scenario.  That in itself is not requiring a HV.  But what runs next is what we should discuss.
  • Nikola: A Type 2 HV can run processes (e.g. camera) separate from a large kernel.  It can continue running that in fact, so no hand-over required.
    • Also possible with Type-1 (which is assumed to be small), which runs a small partition for camera
  • Safety requirements.
  • Android have now published some of their early camera proposals → link?

June 12, 2018

Agenda:

• getting everybody updated
• review of critical use cases.

Participants:

• Kai
• Sang bum
• Berhnard (arm)
• Kevin
• Nikola
• Sriram
• Matti
• Franz
• Gunnar
• Philippe

Apologies:

• Christoph Lipka (ADIT), Albert (Conti)

Minutes

• question on cpu usage following a discussion with a car OEM
  • Sang bum: reports on a discussion on cpu consumption he had with an OEM
  • Gunnar: depends on types of ECU : ic or infotainment
  • Matti: most of systems are very much loaded because as soon as a system has spare capacity OEMs swap to a smaller chip because it costs less

• device driver virtualization
  • wiki page: https://at.projects.genivi.org/wiki/x/ZpT0
  • Matti: posted one hour ago a short intro on virtio in the above page
  • report on review comments on the wiki page postponed to next week

• use cases discussion
  • Sang bum: starts with a question about the use of Android os environment
  • Gunnar: Android has been used for several years w/o support asked from google and w/o certification in mind, now some oems are engaging more closely with Google and look for approval
  • Matti: agrees with Gunnar, Google is heavily pushing their techno into automotive and they will likely agree with the utilization of hypervisors
  • Sang bum: asked whether there is a need to dynamically load an OS (i.e. load android when you want to run an android application)
  • Sriram: this is an interesting requirement
  • Franz: multiplying OSes make things more complex when executing the project (3/4 parties need to manage the project which makes it difficult)
  • Matti: this cannot happen with Apple iOS because Apple has never offered iOS on an hw not designed by them
  • Matti: all other OSes could be loaded on demand, Windows might become something people would like to have, a rear set entertainment is not really automotive, it is rather a tablet, this is why Windows could come back in the landscape
  • [not captured for a couple of minutes]
• back on use cases
  • link: https://at.projects.genivi.org/wiki/x/WpP0
  • Nikola: comments on the challenges column of the table, some challenges are relevant to architecture rather HV technologies, would it be worth identifying them better ?
  • Sriram: yes, this would help
  • Sriram: shows diagram on architecture at the bottom of the page
  • Sang bum: how can SoCrun both linux and rtos w/o virtualization ?
  • Sriram: this is because modern silicon offered the ability to specialize cores  [capture is TBC], almost all infotainement systems were following this architecture up to now, but this is changing
  • Sriram will share more diagrams

• AOB
• Technical summit  - Fall 2018 (week starting on October 8, location: Bangalore, India)
  • Philippe: informs the group that the topics selected for discussion in the summit are related to graphics sharing and hypervisors
  • Sriram: coins the idea of inviting xviser, an HV open source project whose maintainer is based in Bangalore, can reach out to him for a possible presentation, link: http://xhypervisor.org/
  • Franz: what are the results we need to talk about ?
  • Gunnar: [not captured]
  • Kai: what would be the prerequisites to deliver a demo there ?
  • /TODO/ Philippe gather and provide info about the session schedule and space for demos at the Technical Summit
• Adjourned: 11:05am CET
• next week
  • review of Opensynergy inputs on virtual device drivers

June 5, 2018

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, 2018

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, 2018

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, 2018

No posted minutes

May 8, 2018

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, 2018
(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, 2018

Further preparations of AMM agenda

April 3, 2018

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, 2018

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, 2018

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, 2018

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, 2018

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, 2018

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
• 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