Page History

 This contains just some minutes.  Main project page here.

August 14, 2018

Participants:

• Nikola (GHS)
• George Dunlop (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
  

...

• 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
  

...

• 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
  
  

...

• 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

...

June 26, 2018

Participants:

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

...

• 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

...

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

...

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

...

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

...

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

...

• 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

...

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)
  
  

...

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

...

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

...

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

...

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

...

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

...

• 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

...