This contains meeting minutes. If meetings are cancelled this would be noted here. Some dates are missing minutes but ideas are always captured on the main project pages here.
Minute takers according to this page
July 12, 2021
Participants:
- Stephen (Renesas)
- Adam (Kernkonzept)
- Matti (Opensynergy)
- Gunnar (GENIVI)
- Oleksandr (EPAM)
- Kai (EB)
Minutes
- Gunnar: I met with Arm (Bernhard) and Francois Ozog (active in Linaro). We discussed virtual platform specification, if there are additional automotive-specific hardware that need VIRTIO support (e.g. do we have a proposal for FM tuner? (No, not currently))
Discussion on the usage of virtual platforms as a hardware-portability solution:
- Gunnar: We see this trend. I'd like to analyze this idea further, compared to for example just making stable user-space APIs and creating new kernel drivers for new hardware.
- => Is this not just shifting portability work "somewhere else".
- Let's analyze how "virtual platform API is stable" is different from "user-space API is stable" (i.e. just port drivers to new hardware..)
- Adam: BSPs that add a lot of patches to Linux get stuck on older versions. Not using mainline. Updating to new kernel drivers difficult (N.B. officially no APIs are stable inside Linux kernel)
- Matti: Linux kernel in particular, is an operating system kernel and a hardware-abstraction at the same time, which is challenging.
- Future challenges: Value-add for SoCs could be difficult if the [hardware abstraction] API is limiting.
- The virtual platform / VIRTIO / Trout and others. It seems the "new" distinction is a clear focus on a hardware-abstraction layer?
- (partly agreed, discussed the existence of firmware as one abstraction already used, and on PC side the hardware it self was standardized, etc. Overall, a complex reality)
- Summary:
- Kernel updates are driven by fast development, security issues, etc.
- Fast changes, no internal API stability guarantee etc. = updating drivers is a major issue.
- It seems this situation can't be avoided, and the industry is looking for a solution to the challenge.
- The theory seems to be that keeping API stable and efficiently port to new hardware, could be more feasible to do in the virtual platform.
- Discussion turned to evaluating the effort (that the industry is also considering) to create new kernel(s) instead, as a Linux alternative (for safety, and development concerns as shown above).
E.g. if they have a POSIX API, is that "enough". => No... could still be a large effort to port existing functionality.- Gunnar: As an example, consider systemd which early on used Linux-only APIs. And then a lot of functionality built on systemd. Such examples makes porting software a challenge.
- Also discussed how large part of Linux' functionality is actually used in practice in the industry?
- Matti: (Explicit example that shows the current situation)
io_uring recently added to Linux. It accelerates applications a lot. A hardware vendor that is able to use these latest features could have an advantage (hardware itself not faster, but the software runs faster).
- => With a virtual platform abstraction, updating to a new kernel with the new features should be feasible.
June 2021
- Regular meetings held every week. No specific meeting minutes written. Results in AVPS and topic planning (link below)
- AVPS v2.0 release.
- Working on deep-dive topic planning
December 14 2020 → May 2021
- Regular meetings held every week and results tracked in AVPS document and JIRA tickets.
December 7
- Participants: Stephen, Gunnar, Dmitry, Adam, Peter
- GPIO - clarified misunderstanding that referenced SCMI even though SCMI does not cover GPIO. Closed open issues and finalized requirements. Chapter will be done, after final polishing.
- Initial discussion on the structure of final GPU chapter (bringing together all input from previous hardware studies)
- We might need a plausible product design scenario to support the inclusion of VIRTIO-GPU / VirGL based requirements. Also consider how to handle a non-Linux OS, if that is included in the scenario.
Most other requirements will lean on hardware virtualization support, but the group did not want to lose the idea of support simpler hardware too.
- We might need a plausible product design scenario to support the inclusion of VIRTIO-GPU / VirGL based requirements. Also consider how to handle a non-Linux OS, if that is included in the scenario.
- Dmitry has done some updates on Camera/Media – postpone discussion to next time.
November 30
FOCUS : GPU virtualization – Features of the PowerVR/Imagination GPUs (used in Renesas R-Car SoCs).
- Presentation from Thomas Bruss, Renesas.
- Discussing the opportunity for a common "model" of modern GPUs that can be the basis for shared requirements in the virtual platform standard.
November 16 - 23
Discussions captured in JIRA tickets and in the document.
November 9
Minutes pending
...
Participation planning:
- October 19 - GPU focus? Discussion of new Mali features?
Bernhard + Arm colleagues, wants to present Mali GPU- Adam
Dmitry still vacation 
Oleksandr - vacation?- Daniel Stone? Emailed last week. Send calendar invite also.
- Eugen - Emailed
Stephen likely interested- Ozgur - Emailed
- Peter
October 26No meeting (AMM week)- November 2
- Adam
- Oleksandr
- Dmitry
- Peter ...
- November 9 Adam Oleksandr Dmitry Peter ...
- November 16 Adam Oleksandr Dmitry Peter ...
- November 23 Adam Oleksandr Dmitry Peter ...
October 12
- Dmitry vacation, Adam has a conflict this week only
- Oleksandr
- Stephen join if possible (ad-hoc)
- Peter
October 5
Participants: Adam Stephen Dmitry busy Peter busy Oleksandr busy 
Bernhard tried joining (missed by Gunnar)
...
August 31 - September 28
- Another 1-2 discussions on Graphics
- Continued discussion and work on the specification – results are in working document and in JIRA.
Participants:
- Primarily Adam, Dmitry, Oleksander and Kai. Occasionally Bernhard. For graphics also Eugen. Peter had vacation.
August 24
Participants:
- Peter (BMW)
- Daniel Stone (Collabora)
- Adam (Kernkonzept)
- Gunnar (GENIVI)
- Dmitry (OpenSynergy)
Apologies:
Adam noted he has a conflicting meeting this week- Oleksandr / EPAM colleagues – there is a public holiday
Minutes
- Producing the generic model of future GPUs. Adam started writing inside the AVPS as a place to hold the information for now.
Daniel can view and contribute. - Gunnar: That's fine for now. We should work on cleaning up the AVPS for release in the months to come.
- Bernhard: Next generation is fairly fixed but a wish list is useful.
- Peter: It is very valuable to know how Arm engineers think about this. We can discuss common parts of future designs
Gunnar: ... even if Silicon Vendors have their own unique details and/or use some other GPU cores.
Switching to discuss AVPS planning and open JIRA tickets.
Gunnar: A least the "Evaluate Status" column is getting fairly empty. This is good. There are some big ones there still, e.g. DSP/TSP.
- We discussed DSPs primarily. - see notes in JIRA ticket.
Jira server JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 121ddff2-c571-320f-9e4d-d5b9371533bd key HV-17 - Gunnar: There is a lot to sort out here
- 1. Technical organization (like defining the potential software/hardware stack, similar to the GPU discussion)
- 2. ...and as far as the technology is still unclear - understand current project organization (how are projects solving this today, what conversations need to be had between product owner (e.g. OEM), Hypervisor implementor, and the silicon vendor?)
The idea like for any hardware chapter in AVPS, is at mininimum, to try to have a few of those conversations proactively, so that there is a better basis to start from when going into a production project, and as far as possible, create some generic solutions/standards that remove obstacles.
August 17
Apologies:
- Dmitry
Participants:
- Peter, Adam, Oleksandr, Gunnar
Graphics discussion not fully successful today due to missing key participants, but we collected the thoughts of those who were here.
Graphics
Let's recap our thoughts and conclusions from last week's discussion
Adam: I have always thought you need hardware support to do this properly. But of course if you are already in another situation you might have to do something different.
But [the hardware-assisted solutions] involve NDAs and binary blobs (that are more difficult to analyze generally).
Peter: We discussed some similarities and a working model last week, the idea of the command queues that seems to be similar in future solutions. There are some special support for video and others. I would like to achieve this model that can progress this without being too specific on one solution. It may also avoid NDA issues. Find these common abstractions to work on. Multiple hardware should be able to be mapped into this.
Peter: We need to consider about composing images also - the display output (2D). When this is combined with other video feeds, there are safety concerns that need solutions.
Gunnar: There are some patterns for handling safety (e.g. fallback to simpler HMI if the advanced one is fails (recognizing failure in various ways)), and these patterns may drive our standardization approach.
Peter: These patterns are useful. Also considering that there are different needs - not all platforms require ASIL-B, for example.
Oleksandr: I'm not as focused on the graphics subsystem, so it's hard to say that much and what we are doing concretely is covered by NDAs. We have experience with hardware that has hardware-assistend virtualization support and we are implementing such things in Xen.
Some hardware has implemented more than one GPU and can use simple pass-through of each of these to for example 2 VMs.
Gunnar: Discussion last week with Daniel and others led to the conclusion we should start this "general model" discussion with the implementers of future graphics hardware. I feel like we need to produce a description that we can bring with us to start that conversation.
Adam: I would like to give it a try. (This week)
Gunnar: Great, and then Peter may want to add to this.
Power Management
Oleksandr: I have made some proposed edits. SCPI should be deprecated because it is now covered in SCMI and we should require the 2.0 version of SCMI.
IOMMU
Oleksandr shares some experience from Xen implementation.
Further discussion how to bring the chapter to a close, in particular the 2-stage IOMMU question that is still not brought to full conclusion.
...
August 10 – Graphics/GPU focus
Participants
- Daniel Stone, Ozgur Bulkan, Adam, Dmitry, Peter, Gunnar, Oleksandr, ... ? (I missed recording the full list)
Gunnar introduced the AVPS goals a bit and mentioned that in some hardware areas (and almost surely for GPU), the AVPS specification can/should not reach the point where it requires only one way of doing things. It can still be useful to dig deeper into a few things, and then describe a few different choices through optional or conditional requirements. It is still much more useful to have that analysis done when a production project starts than to have a blank page.
Daniel: Requiring Vulkan would make sense but will not be supported everywhere so unfortunately it cannot be the only choice. GL API is stable.
Peter: [We need to discuss] technology roadmap for next generation GPUs (HW support for virtualization)
Daniel:
ARM, Renesas, Qualcomm, others would need to discuss this to get the information, but everything might not be shared.
...HV vendors implement this when the technology is ready (NDAs)
Every VM has it’s own virtualized GPU. Dedicated command queue per VM. Buffer handling can be challenging (sec/safety, etc.) It gives you a “direct access” to the hardware. Normal drivers and software can be used, because it looks like a GPU.
Peter: Can a standard model for GPU be defined which can help development (of specification and code/solutions)? Command queue is common for all.
Daniel: Concentrating on the API definition which can be generic, and over time hardware support could make the implementation of it easier. This is the VIRTIO queue API level.
Ozgur: What about the original VIRTIO-GPU 3D specification
Daniel: It is similar to VirGL but was not quite the same.
Discussion would be needed with the real graphics engineers (within ARM, Imagination, Qualcomm….) to see if they are open to discuss standard APIs in one level.
Ozgur: Vulkan path is yet another choice?
Daniel: Conceptually similar. Host/HV would still need to manage resources, track all the Vulkan objects, buffers, textures, targets. This is the same for virtualization of Vulkan and OpenGL.
Ozgur: SoC providers do not want to rewrite their implementation (e.g. to support VIRTIO queues [or other standard virtualization API] Basically they provide everything from user space APIs to the hardware…
...
Daniel: Yes, I agree. Hardware independent and hardware dependent APIs will likely be different APIs. We can (only) expect a few basic things about HW dependent (using channels/queues and buffer handling).
Ozgur: VIRTIO is only concerned with multi client rendering?
Daniel: Yes, it does not handle multi leases and other more complex situations.
Ozgur: Can we start thinking about things like nested compositors?
Daniel: DRM/KMS provides some capability for HW compositors but not the constraints you need (to match the (virtual) hardware capabilities).
Ozgur: Will it need kernel/driver changes?
Daniel: It’s primarily the API side for virtualization.
Daniel: Way forward. Split the problem.
1. Write how we think a fully hardware specific path will work. (a generic model for how w e think HW assisted virtualization is done)
2. The fully generic VirGL / vulkan path. We can start encoding more specific requirements.
Ozgur: What can be implemented to test this now?
Daniel: VirGL already works on top of any OpenGL (GLES) implementation. Mesa, and also others.
Way forward
Daniel: I’m happy to encode the requirements that we have already today in VirGL. Over time I can try to do the same for the Vulkan path. For the HW specific approach, can we reach out to the platform vendors? or HV implementing companies that are likely implementing some of these things now [with the latest hardwares].
Gunnar asks Dmitry to see if there is a way to have a (private) conversation with potentially ongoing commercial implementation projects, to draw the boundaries between what could drive the specification content (and what could not).
Peter: The model approach is very good because we would then be less dependent on the hardware vendor proprietary information while this is being built out.
Gunnar mentions that ongoing work should be complementary and can together improve the situation, from specification side, and from trying out implementations on AGL and other projects. The AVPS work provides the API specification, ensures multi-OS aspect is not lost, and aims to influence AUTOSAR and other industry initiatives to align on a common way forward [based on the open development of AVPS].
Daniel: It would be useful to get Panasonic’s input since they drive a lot of implementation in AGL for virtualization.
Gunnar: Yes. Both the implementation and AVPS is VIRTIO focused which should help compatibility.
July 20
Participants
- Dmitry
- Adam
- Oleksandr
- Kai
- Gunnar
Introduction to Oleksandr (EPAM), working on VIRTIO support in Xen. He has lately worked specifically on implementation on IOMMU on Renesas platforms.
Discussed again how to rewrite Camera + IOMMU from scratch with all the new information we have gathered
(It is currently disorganized, but has a lot of good knowledge).
Actions for Dmitry and Adam to do this rewrite.
Gunnar on vacation next week. Do you want Philippe to open the call?
Adam: I will work on the chapter, I don't need the phone call for that.
=> Next week will be skipped.
Absence planning
See July 6 and
+ Gunnar, away (this week) and next, and probably again end of August (1 week)
+ Kai - mid August 17 August → 6 September
+ Oleksandr - possibly starting last week of August → 2 weeks
Kai found an interesting paper from Strategy Analytics. Plan discussion about it later on.
July 13
Additional work on Camera and IOMMU with Dmitry and Adam - results in document.
AI: (Media and Cameras) Gunnar to work on combining original and new text to more logical flow.
AI: (Media and Cameras) Dmitry to also review red text in the same chapter
Info: Let's plan for Graphics oriented meeting some time in the future, inviting Daniel Stone.
Be aware of presentation that Daniel also posted to the GPU related Wiki page.
Info: Gunnar likely to have vacation some time after next week's meeting.
July 6
In-depth review and improvement of Cameras chapter → results are in the working doc.
EPAM colleagues missing, will follow up those topics next week.
Vacation planning
Peter - No vacation until Mid September
Dmitry - same for me, probably October at the earliest.
Adam - similar, nothing planned at the moment...
Gunnar - end of July / beginning August. Will specify better soon.
June 29
Apologies from Artem + colleagues (public holiday), Peter (unexpected mgmt escalation), Adam, etc.
Have no info from Dmitry or Matti about attendance today. Also not from Kai.
Other participants (Matt, Bernhard) are more attending on-demand / occasionally and were not expected today.
=> Meeting is skipped.
June 22
AVPS v2 work:
Continue discussing with Artem and Adam on IOMMU including programmability from guest, and requirements for coprocessors. We are getting there. Adam will try to rewrite once more.
Artem: I am sending over details that might be interesting, about the implementation for co-processors on Xen:
- Co-processor_management_under_xen.pdf (XenProject website)
- XPDDS 17 keynote (Slideshare.net)
Went through comments and minor changes in the whole document and accepted all minor changes. Open points kept for discussion with a few others.
Need time to discuss with Dmitry on changes in Media chapter and more.
Artem: I intend to involve 2 new colleagues into this work.
April 27 - June 15
Meetings held as usual, except for some bank holiday.
Minutes have not been recorded separately. Instead, discussions and updates on the Automotive Virtual Platform Specification have been recorded directly in the working document as text and comments. The JIRA Tracker is also used to track updates and assign tasks.
April 20
Participants
- Bernhard Rill
- Adam Lackorzynski
- Dmitry Sepp
- Matti Möll
- Gunnar
- Alex Agizim (EPAM)
- Kai Lampka
Apologies
- Peter (Zoom was blocked?)
Minutes
Went through tickets.
Discussed development support ticket → DLT discussed at some length. Various "known" discussion points (ID uniqueness, on-disk storage format, common timestamp references) but they become more relevant in a Hypervisor setup.
Kai reviewed Booting chapter and found a few issues/unclear direction. Moved chapter to "Improve" column.
April 13 – no meeting (Easter Monday)
April 6
Minutes pending
March 30
Participants
- Bernhard Rill
- Peter
- Adam Lackorzynski
- Dmitry Sepp
- Matti Möll
- Gunnar
Apologies
- Artem (conflicting meeting)
Minutes
- Peter: Defining the platform better. The Arm specification on secure partitioning can also be useful to look at.
- This also includes use-cases, to better define...
- Bernhard: Yes, and a few other specifications might be useful also. Others are not so applicable. I can look at this.
- Peter: Starting with VM scheduling, for example.
- Matti: We can only define the interface... what other "surfaces" might be described?
- Peter: Just thinking that going from the top we realise VMs need to be scheduled.... Example - Android + RTOS, how is switching done and what does it lead to?
- Gunnar: This goes into a kind of system design. If you are speaking about cores etc.
- Bernhard: Two prominent examples of interfaces...
- Matti: Define what is a platform in general, and is it focused on components or interfaces?
- A platform allows things to be built on top of it. It cannot be too hard to implement, because then it will not be implemented to the degree that it becomes really usable.
- Think about the right level. Not too complicated. Not narrowing the solution space too much. And not too broad so that portability is not achieved.
- Peter: We are quite well defined here. Starting from defining a... hypervisor based platform
- Matti: If it is an automatic (preemptive) scheduler, it cannot be defined using interfaces.
- Gunnar: You can set priorities. Not from the VM, but when configuring the platform. (Therefore the AVPS could set requirements on it).
- Peter: We can still write requirements for this. The behavior can be defined.
- Peter: Variants of the platform advanced/basic could be an example.
- Matti: Currently covered in AVPS by "If the platform includes feature X, then it must..."
Short review (on overtime) of the AVPS v2 ticket priorities.
March 24
Whitepaper work and AVPS prioritization
Minutes pending
March 16
Whitepaper work and AVPS prioritization
Minutes pending
March 9
Participants:
- Dmitry
- Kai
- Adam
- Peter
- Michael
- Gunnar
- Philippe
...
- But should we also include challenges that are added as a result of choosing virtualization?
For example shared-memory as discussed in the comment by Michael on Whitepaper - first private draft text
Discussing shared memory challenges:
...
- Introduction and welcome to new participants
- Review current work topics and purpose with new participants
- We went through the status of the the Virtual Platform definition work, updating the table and some few changes in spec text
...
- We went through the entire table of status for information and for updating, looking into the draft specification chapters to confirm the current content.
- Last part of table needs to continue next week.
...
Short meeting because of few attendees. We expect some are preparing for next week F2F ;-)
Sync up on whitepaper work and review with Kai after absence.
Discussing F2F logistics and whitepaper planning.
...
More discussion on whitepaper content and plans for who will write which chapters.
September 03, 2019
Participants:
...
- Kai (vacation)
- Bruno (conflict)
Minutes
- Discussed the Whitepaper draft content and the result was added using green text.
- Outline/content of the inter-core communication was added with Matti's input
- The document purpose was futher discussed and ideas were noted in the beginning of the document
...
Discussing the "outline" (general content and order of content) of the first draft in the page Review of content/outline for the early draft of HV whitepaper
Most notes taken on that page directly...
...
- Bernhard/Gunnar: ARM is still waiting for input what ARM can bring to the F2F.
- Bernhard: On the whitepaper side, Chapter 2 seems like we can help. But it is very hardware dependent. There should be some info how hardware features evolve. In this ARM can contribute.
- Gunnar/Bernhard: Open question for team/writers to answer: HW needs could be reflected differently in the architecture - more generalized, or specific. Likely there might be a few specific examples from ARM. Sometimes examples are even more specific than what is described in generic-ARM (in other words a specific SoC might have added a unique feature).
- Bernhard: Example SCMI presented before, we can extend on that and/or TrustZone
- Gunnar: Start Attendance list. I will add it on F2F agenda.
- Bruno: I cannot join the F2F in September - travelling for 3 months.
- Gunnar: Please consider if another engineer near you can support networking chapter finalization in Virtual Platform specification
- AI:(all) Review F2F agenda and give feedback on the content and alotted time for each topic.
...
- JIRA project work
- Matti convert the virtual platform "table" to tickets
- Kai still interested to write but ran out of time. New attempt for next week.
- Break down the work by writing some JIRA tickets (Kai).
- Next week: also Discuss F2F agenda
...
- Link to whitepaper planning (scroll down to see proposed document outline) [HV] Next Generation Multi-OS System Design Whitepaper
- Vasco offered to start writing a chapter, or much more detailed outline of the chapter. I.e. what's the actual content.
- Proposal to switch meeting time came up again
...
Discussion about project organization. Should we get our ongoing work up on JIRA tickets for more clarity?
Gunnar: We started this a bit more ad-hoc and driving forward with tables and minutes. [...but we have not so good delivery accuracy...]
Most other GENIVI collaboration projects use a lightweight SCRUM with some defined sprint content, depending on people availability.
JIRA is successful in several other projects (Android SIG, Connected Services, GPRO/Franca-ARA:COM and others) (NOTE: some links might require you to log into JIRA)
...
Gunnar: Can you provide links to upstream / blog etc.?
Dmitry: Already in Wiki see IOMMU Summary
Dmitry: Matti will be in office next week, then away for 3 weeks. Planning to upstream more patches.
...
- Lots of topics (5 presentations), lots of discussion
- Little time for Q&A on each - basically every topic needs deeper investigation and discussions
- See presentations
May 14 - cancelled due to AMM
...
- Introduction, Steve Liu
- Recap of USB discussion. Findings and still open questions.
- Discussing adoption of standards. Do OEMs need to require this in RFQs before it takes off? (Similar: Do OEMs need to require VIRTIO, for non-VIRTIO hypervisors to implement it?)
- Planning Workshop content
...
April 23, 2019
Participants
...
1. Come to a (personal) proposal for your section and document this (is VIRTIO adequate, what else is needed, etc. The process that is mentioned on working page
2. If we feel uncertain, e.g. must have more use-cases, write that down. What is required for you to reach the point of 1.
...
AI (Anup): Pick a topic to lead. A free one, or you can also add to one that already has a name.
October 11, 2018 - Tech summit working session in Bangalore, with phone conference
...
The overall plan for working session is at:
HVWS Workshop Schedule at Bangalore Tech Summit
A few people asked for a more exact 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 ?
- 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
- 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
...
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
...
- 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
- Write down / figure out the automotive requirements
- Read VIRTIO chapter
- Decide if VIRTIO is appropriate and complete for requirements (Gap Analysis)
- 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.
...
- 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.
- Just for reference: 1 second Linux Boot example (old) (not snapshot or hibernation, if I recall correctly)
- 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
...
- 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
...
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.
...
April 19, 2018
(Full-day All Member Meeting Workshop)
Please see the Hypervisor Workshop Schedule at Munich AMM 2018 page for schedule, speakers, participants and meeting 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
...
- 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
...
- 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)
...
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
...
We simply discussed and filled in the topics under Hypervisor Project. Discussion much driven by Albert and Christoph.
...
- Introductions
- Gunnar tried to get contact with Ajmal, Gayathri, Karthikeyan, George, and some others but no answer.
- Apparently there were microphone troubles all around
- Gunnar tried to get contact with Ajmal, Gayathri, Karthikeyan, George, and some others but no answer.
- 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
...