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.
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:
Minutes
Discussion on the usage of virtual platforms as a hardware-portability solution:
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).
June 2021
December 14 2020 → May 2021
December 7
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:
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 Adam Oleksandr Dmitry Peter ... Adam Oleksandr Dmitry Peter ... Adam Oleksandr Dmitry Peter ... Adam Oleksandr Dmitry Peter ...October 12
Dmitry vacation, Adam has a conflict this week only Oleksandr Stephen join if possible (ad-hoc) PeterOctober 5
Participants: Adam Stephen Dmitry busy Peter busy Oleksandr busy 
Bernhard tried joining (missed by Gunnar)
August 31 - September 28
Participants:
August 24
Participants:
Apologies:
Minutes
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.
August 17
Apologies:
Participants:
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
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
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:
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
Apologies
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
Apologies
Minutes
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:
Minutes
Gunnar Presented Webinar-Report draft. Purpose and content. Recommended reading for all, but especially those who did not attend.
AMM plans: GENIVI All-Member Meeting planned for May 12-14 in Leipzig, Germany
AI (all): Block 12-14 May (+ possible travel time) in your calendars.
Discussing the comments given in whitepaper editable document, and many general discussions about the direction and content.
AI (all): Get your (Google) account connected to the document, with edit capability AND everyone expected to give some input until next time.
March 2
Participants:
Minutes
February 17, 21, 28
Minutes pending
February 10
Participants:
Whitepaper:
Discussing shared memory challenges:
Locking implies timing interference. Lock-free implementations are complex but important. Can hardware support be provided to improve the implementation of shared memory implementation?
Kai: You would sacrifice isolation if different criticality functions access the same memory.
Adam: For video the approach be fine as long if data corruption is less of a concern. Depends on the use cases of course.
For sharing it is required to consider hardware support for making some access read-only to guarantee that non-critical software cannot change the memory values of critical software.
Gunnar: What about if there is only one writer (critical task) and multiple readers. Can non-critical readers negatively affect critical software by starving the memory bandwidth or similar?
Adam: Generally starving is not possible due to hardware setup. A worst case analysis would be needed.
Adam: Hardware counters usually exist that can enforce budgets on the memory usage. Usually two counters or so, the number of counters might not be enough.
Kai: How do the lock-free implementations perform in worst-case situations?
Dmitry, Kai: Locking (handling multiple writers or handling that writing is complete before reading starts) is orthogonal to the performance issue.
Gunnar: One detail, don't forget buffer sealing (as Linux calls it). It is a security feature (needed for some use cases) to set a buffer read-only as it is being handed over. This is to be able to guarantee that a writer does not modify the buffer again, after it has been handed over to the reader(s). Such late modification could be used by a malicious writer to exploit bugs in the reader implementation.
Conclusion: Yes, it might be useful to include, in the white paper, some challenges topics and how to solve them (e.g. shared memory).
Gunnar to send out links to webinar. Participants invite their colleagues.
Weekly meeting, February 3, 2020
Minutes
Weekly meeting, February 27, 2020
No minutes
Weekly meeting, January 20, 2019
Restart after new-year, CES, etc.
Spec has been released. Dissemination/information given to various automotive industry individuals during CES.
Matti is away from project for a while.
New JIRA items, one per "chapter" to track which parts need update.
Some additional edits will be done by OpenSynergy tech-writer (Susan)
Action to all: Each participant finds at least one colleague/friend to show specification to for feedback.
Webinar is being planned beginning of February.
Artem: For Xen we are quite busy atm, working on safety certification, some ELISA project participation, and of course virtio implementation...
No progress on whitepaper - need leadership to assign tasks/chapters in practice.
Weekly meeting, December 9, 2019
Rough minutes: Went through spec from the last page in reverse. Discussed open points.
Actions taken by Adam to update
Weekly meeting, week of December 2, 2019
Participants
Apologies/Absent
Agenda
Discussing graphics/memory buffer sharing.
libvirgilenderer implements the API, including reference implementation of VULKAN API
In practice there will be only one implementation. It might make sense to require using libvirgilrenderer quite simply.
The driver is part of MESA project.
Non-virtual operating systems? QNX apparently ported both driver & renderer part.
Integrity? MESA driver is a user space library - creates a command stream - should be easily portable (paravirtualization assumed).
Eugen: There was a proprietary API for memory sharing proposed in...
...Other APIs just give you a handle, and you don’t really control what happens below.
...Should there be a defined way how memory can be represented in a generic way?
Matti: VIRTIO basically is this in fact. The scatter-gather lists are providing this. Managing the lifecycle of the buffers is the challenge. Gerd Hoffman / RedHat has proposed a standard - see virtio list. (https://lists.oasis-open.org/archives/virtio-dev/201911/msg00149.html)
Need to build in handling of the particular characteristics of the hardware. E.g. special alignment or size restrictions. Usually VIRTIO has per-device handling today (GPU, block-device, … ) because of this.
Intel created a proposal to require host to allocate and give to the guest. Memory accounting troubles follow. This was not accepted in the community.
recent proposal VIRTIO-GPU resource attachment. patches to qemu to get a DMA buffer from a guest target buffer. udma (in qemu). This could be applied to embedded HVs.
create_memfd - filedescriptor. udma driver - ioctls to control it. See DMAbuf in Linux source. drivers/dmabuf/udmabuf. Note memfds are not part of POSIX standard.
Gunnar: These are Linux specific APIs then. Any different consideration for non-Linux OS (in a virtualization environment).
Matti: Should even be easier to implement in simpler OSes (since user space code may be more privileged to access the details).
Matti: One answer is that the GPU 2D specification already allows sharing buffers. You have to keep into account some details about the memory model of the HV.
VMs can tell the HV environment about buffers they would like to show, including giving this buffer to another VM.
Some kind of global compositor and it is given the buffers, e.g. that compositor might be within one VM, but it could be a hardware display device...
How to handle the lifecycle of the buffers?
Matti: VIRTIO specifies a low level way to communicate between VMs with virtqueues. The other is the description of the device implementation. How to handle the scatter gather lists of buffers.
Gunnar: The discussion involves different standards, in addition to standard Linux/Wayland, there is for example the Android graphics stack, potentially others...
Wayland can display a DMA-buf so if only you can get a handle to that, it's one way.
AVPS completion work
Weekly meeting, week of November 18, 2019
Minutes
Intro and discussion with Gaurav. AVPS work - documented in the google doc itself.
Weekly meeting, week of November 18, 2019
Participants
Apologies/Absent
Minutes
Weekly meeting, week of November 11, 2019
Cancelled due to Tech Summit. Not everyone was aware though.
Weekly meeting, week of November 4, 2019
Participants
Apologies
Minutes:
Weekly meeting, week of October 27, 2019
Weekly meeting, week of October 20, 2019
Weekly meeting, week of October 14, 2019
New meeting time used today, Monday 10:00 CEST
Participants
Minutes
Weekly meeting, week of October 9, 2019
Meeting missed/skipped due to ongoing rescheduling
Weekly meeting, October 1, 2019
Participants
Apologies
Minutes
Tech Summit, November 12-13
New meeting time
Virtual Platform Status
Other
Adjourned (late) at ~11.35
F2F meeting, September 24-25 2019
Some rough notes from F2F were captured here. Cleanup in progress
F2F September 24 - notes to be copied to the right place... Motivation: Why to use HV:Opinions on the high level purpose of the paper. Interaction between general-purpose and dedicated cores is poorly understood. 3.2 Network Device Standard networks Standard networks include those that are not automotive specific, but instead frequently used in the computing world. In other words these are typically IP based networks, but some of them simulate this level through other means (e.g. vsock which does not use IP addressing). The physical layer is normally some variation of the Ethernet/WiFi standard(s) (according to standards 802.*) or other transport that transparently exposes a similar network socket interface virtio-net = Layer 2 (Ethernet / MAC addresses) Discussion: vsock is the application API. Multiple different named transport variations exist in different hypervisors which means the driver implementation differs depending on chosen hypervisor. Virtio-vsock however locks this down to one chosen method. Requirements:
------------- 1. IntroductionAutomotive requirements lead to particular choices and needs from the underlying software stack. Existing standards for device drivers in virtualization need to be augmented because they are often not focused on automotive or even embedded, systems. Much of the progression comes from the IT/server consolidation and in the Linux world, some come from virtualization of workstation/desktop systems. A collection of virtual device driver APIs constitute the defined interface between virtual machines and the virtualization layer, i.e. the hypervisor or virtualization "host system". Together they make up a definition of a virtual platform. This has a number of advantages:
In comparison, the OCI initiative for containers serves a similar purpose. There are many compatible container runtimes standardized "hypervisor runtime environments" that allow a standards compliant virtual (guest) machine to run with less integration efforts.
|
September 17, 2019
Participants:
Minutes
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.
September 10, 2019
Participants:
Apologies:
Minutes:
Matti: I think the draft covers a good outline fairly well
Gunnar: Conclusion chapter
point out what is out of scope
Gunnar: Reasonable point not to include everything
Bernhard: Several ARM features supporting this, we have provided
Currently, includes when to use paravirt, hardware support, isolation generally.
Artem: Useful to include some example of what different HW vendors include (e.g. for inter-core communication as discussed last week)
Artem: Power management is also important
Bernhard: Also S-MMU is such a related feature.
Matti: Travelling next week, 1AM time slot. Will try to join.
Discussion on F2F agenda.
Action (Gunnar): It is time to send out invitation/information about the F2F to mailing list.
More discussion on whitepaper content and plans for who will write which chapters.
September 03, 2019
Participants:
Apologies:
Minutes
August 27, 2019
Participants:
Apologies:
Minutes
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...
Action: Dmitry to try to find time to draft some I/O challenges leading to need for IOMMU and eventually need of Virtual IOMMU... (as needed by whitepaper)
... but this week is very busy....
Action: All to look over/adjust F2F agenda
Bernhard: Still considering what we can contribute to chapter 2 in terms of new coming hardware chapters.
August 20, 2019
Minutes pending
August 13, 2019
Apologies
Participants:
Minutes
August 6, 2019
Participants
Apologies
Agenda:
Minutes
Philippe: points to the proposed document outline available at the bottom of [HV] Next Generation Multi-OS System Design Whitepaper
July 30, 2019
Apologies
Participants
Minutes
July 23, 2019
Apologies
Participants
Minutes
July 16th, 2019
Participants
Apologies
Minutes
Video virtualization standards update (Dmitry):
V4L2 is stable but Android is the main challenge because of a lot of changes and new development. Changing from OMX (older API) to Codec2 - new HAL/API, operating on top of OMX (backward compatible) and V4L2 and other.
Some video accelerator technology coming in from ChromeOS / Chromium.
Dmitry: We haven't approached VIRTIO with any proposals yet. Need a bit more stability first.
Gunnar: In your opinion how is Android regarded in the upstream VIRTIO work? Or are most of the participants primarily focused on Linux / QEMU ?
... seems primarily Linux / QEMU is driving still.
Dmitry/Gunnar: CrosVM is a hypervisor monitor in ChromeOS. It uses KVM as the control interface to the kernel.
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)
Discussing F2F agenda
Gunnar: Originally, we said to focus on the virtual platform specification.
Dmitry: Agreed, primarily specification. But what do the others think?
Gunnar: Note that Participation from Kai will be not every week - Adam is supporting on similar topics.
Adam: My main area of knowledge around VIRTIO is also block device and storage, like discussed with Kai before.
Gunnar: Please consider if you can help out to write the Block device chapter into the specification.
AI (Gunnar): Contact Artem again.
Meeting adjourned 10:40.
...then Kai joined.
[We had a quick sync up between Kai & Gunnar]
Kai: I have a conflicting meeting every week but sometimes I can join a bit late like today.
Gunnar: OK, let's try to work with that somehow.
... mentioned JIRA idea as above
Kai: ... OK, maybe useful for whitepaper delivery.
AI (Gunnar): Look at setting up JIRA project for HVWS project
F2F agenda
Gunnar: What do you think should be the main agenda for the F2F? Virtual Platform Specification?
Kai: Yes, primary focus on specification, some whitepaper sync up (assuming draft is done before September)
Kai: I think everyone can write a chapter in the whitepaper, we could get a draft ready by September. Let's agree on the
Gunnar: Currently the primary outline is based on your combined proposal. I only left the other chapters at the end as a kind of history and possible to select some ideas from.
It also includes our brainstorm at the top, so the page is a bit messy now. Let's move the agreed outline to a separate page/document for clarity.
Kai: I will work on this.
Kai: Next week I expect to be able to join also, perhaps a little earlier.
Future absences:
Kai: Last week August, first of September
July 9, 2019
Participants
Apologies
Minutes
Known absences as of today:
Franz - last week of August and also first week.
Bernhard - much later (November)
Dmitry - no plans so far
Gunnar - TBC. Likely last week July and beginning/mid of August
July 2, 2019
Apologies
F2F workshop decided : Sept 24-25.
Kai presenting starting point for Outline
Matti: Some parts of the system such as clock control need to be isolated from... E.g. clock controller for Ethernet network needs to be under the control of an equally safe part of the system. Use a safety island or a VM responsible for this. Some tension between hardware vendors providing such features and the proponents of hypervisors.
Adam: You can also mix this stuff. Lay it out as you need it.
Gunnar: This is what I mean about design guidance. Present choices, present consequences of choosing, and then
Lots of discussion on scope and possibility to include the Design Guidance (mostly between Gunnar and Kai)
Kai wrote some additional points down during discussion and will send them over. Most likely these will be integrated into the whitepaper guideline.
June 25th, 2019
Participants
Apologies
Minutes
Dmitry: We follow VIRTIO block device standard.
Adam: Other than the trim/discard stuff we have noted is missing, we have no issue with VIRTIO block device standard. It is fairly small after all. There's a patch for Linux, it should be merged now. Eventually it should show up in VIRTIO
Adam: The trim/discard has been added to VIRTIO 1.1
Gunnar: Let's complete the spec - write a few requirements into the block device chapter.
Kai: We can do that
Dmitry: We don't really use it but VIRTIO should cover this. It is quite mature.
Gunnar: Let's review the crypto support chapter in VIRTIO
Dmitry: 2D is fine.
Dmitry: 3D is still changing. Android will require Vulkan. New versions should be based on Vulkan. Someone needs to introduce Vulkan support in EGL renderer or everything move to Vulkan.
Gunnar: Not moving fast enough to get to a stable point yet, then?
Gunnar: Vulkan support on the driver side?
Dmitry: Android Emulator should need it. Google might be working on it?
Vulkan support exists on bare metal hardware (GPU vendors provide it) but not yet for virtualization. This is a kind of showstopper for Android in virtualization in the future.
Gunnar: Is there a minimal set of requirements to write down today?
Dmitry: 3D part is still a big question. It's hard to decide on the requirement set.
Input
Dmitry: We have some implementation of this spec.
Adam: vsock can be used for VM to VM communication.
Adam: The user level APIs are normally standard socket APIs so that is convenient
Gunnar: But can you assume all features work? Let's say I select/poll on the vsock, and other file descriptors, will it work:
Adam: Impl by kernel...
...Alternative: VIRTIO console/character device. But that's a different interface.
Dmitry: One of the stty needed to change to RAW data transfer and then it's available.
Gunnar:
9pfs
IOMMU -
Dmitry: Lots of updates still, upstreaming. When that is done I will look at the final specification and update chapter, should be about 1 month or so.
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.
Adam:
Sensors
Dmitry: From mailing list: OASIS don't want to accept any sensors. In the end it's just a byte transfer.
June 18th, 2019
Participants
Apologies
Minutes
Whitepaper scope, followup
F2F
Doodle for F2F:
https://dudle.inf.tu-dresden.de/Genivi_HVWS_F2F_Workshop_September_2019/
Number of days? 2 or 3, let's create another poll
https://dudle.inf.tu-dresden.de/v5fxnz31/
AI(all): Fill in both of the 2 Doodles
MCU Hypervisors
Bernhard showing 2 slides (taken from a 162 slide presentation - there is more info of course)
Cores The R7 well known, R52, brand new.
Can control who has access to physical memory
RTOS1 & 2 in the picture accesses physical memory directly. Note still NO address translation.
Multiple RTOS, multiple classic AUTOSAR stacks, for example.
EL-2 MPU is the new one.
You could integrate a rich OS without letting them know they run on the HV.
Applicable only for Cortex A profile only
Hypervisor could be used but trapping accesses would be costly
Better to have operating systems are fully aware/designed.
Separation Kernel might be a more apt name for this simple partitioning (academic discussion)
Changing timing of RTE on a classic autosar stack may need recertification (for critical functions).
With this add on, a safety-critical (ASIL B) can be isolated and guaranteed its resources. – by running more than one complete AUTOSAR stack, in partitions.
Another case: Software updatability – some parts are updatable through SOTA and others cannot be affected.
Note Double or triple memory requirements. (because multiple AUTOSAR stacks) but it might be worth it.
Another use case: Heterogeneous designs. Safety Islands (often implemented in R7).
Known/publicly available info about licensees: NXP, ST and DENSO.
(i.e. R52 silicon is available now)
Adam: On the term "Hypervisor" Some call it Virtualization even when there are only very simple hardware separation features built in.
Note that Other MCU vendors with even less capability built into hardware are using the term "Virtualization support".
From Matti Möll to Everyone: 01:48 AM
http://www.projekt-aramis.de/
From Bernhard Rill to Everyone: 01:49 AM
https://www.aramis2.org/
Matti: A related info from OpenSynergy
https://www.opensynergy.com/wp-content/uploads/2018/06/Hypervisor-for-latest-NXP-microcontroller.pdf
Stephen: Renesas related info: Trustzone security extensions, a similar concept was applied in the R7. See documentation in the Lifecycle documentation for the SoC.
June 11th, 2019
Participants
Apologies
Whitepaper Discussion
June 4, 2019
Minutes by Kai Lampka
a) White paper: discussion on potential sections. -everybody is aksed to llok again at https://www.automotivelinux.org/wp-content/uploads/sites/4/2018/06/GoogleDrive_The-AGL-software-defined-connected-car-architecture.pdf
For inspiration.
(i) Why are we doing this motivation also addressing heterogenous multicores:
(ii) Use-case of SoC partitioning into safety- and security islands.
(iii) Clarification of terminologies, para-virtulization, TCB, microkernel-based approaches, monolithic HV, type-1 and type-2 and embedded HV
(iv) What HW can do for isolation resp. platform partitioning
Please consult https://static.docs.arm.com/ddi0598/a/DDI0598_MPAM_supp_armv8a.pdf
for inspiration.
(v) VirtIO as mean of
b) Meeting on Virtio in Berlin AI: Kai sends doodle link to Gunnar):
c) Status of technical discussion (needs attendance of Artem), we defer this.
May 28, 2019
Participants
Agenda
May 21 30, 2019
Participants
Agenda
Minutes
Some notes from workshop: Hardware Souvik presenting for ARM |
May 16 - AMM workshop
Participants
Minutes
May 14 - cancelled due to AMM
May 7
Few participants
Minutes TBD
April 30, 2019
Participants
Apologies
None
Minutes
April 23, 2019
Participants
Apologies
Minutes
USB Virtualization
AMM
April 16, 2019
Participants
Apologies
Minutes
Booting
April 9, 2019
Participants
Minutes
Booting
ARM SBSA Debrief Contd
April 2, 2019
Participants
Minutes
ARM SBSA Debrief
raw notes (to be checked by Gunnar)
HV Workshop topics
March 26, 2019
todo
March 19, 2019
Cancelled
March 12, 2019
ARM Presentation on Server Base System Architecture
March 5, 2019
Minute taker: Vasco Fachin
Hypervisor Genivi Meeting Meeting Minutes 05.03.2019
Participants :
Vasco Fachin
Gunnar Andersson
Philippe R
Dmitry Morozov
Franz Walkembach
Bernhard Rill
Later:
Sang-bum Suh
Much Later:
Stephen Lawrence (Renesas)
# Notes
Gunnar: Sang-bum Suh contact over email, should join today
Franz will join the Renesas Meeting, Philippe will show the Demo done at CES
## Summary of last week
Gunnar: Review of last week. Kai's proposal for the new topic, then talk about physical and virtual Audio Driver. Input from Matti. Information is present in the wiki page. Open Sinergy has a proposal for a VIRTIO Audio.
Franz: Shared audio from Hypervisor perspective.
Gunnar: Shall be similar to what Matti presented. Maybe you (Franz) can take a look at what's been discussed.
## AMM Partecipation
Gunnar: Waiting for Sang-bum Suh, looking at the AMM attendance.
AMM company overview/experience on how what to deal with hypervisors: SysGo, EPAM, OpenSynergy have been reached out.
Dmitry: Have to check if this is possible
Gunnar: Artem and Lars (Xen) have already planned the session.
Sang-bum, Bernhard (maybe other collegues) joins AMM, Dmitry and Matti probably not, Franz will probably not join. Vasco has to clarify.
## SBSA
Bernhard: Next week we shall have the SBSA presentation at 11 CET. If there is interest, some people from ARM could join the AMM meeting. Needs to be clarified until next Tuesday
## Security
Sang-bum: Hypervisor System Architecture includes Cryptography.
Root of trust: Hardware provides unique random number used for crypto modules. The Crypto Function can be used among different OSs. Depending on how many OSs are depending on the underlying crypto modules, these might be virtualised.
- TPM service cannot be multitask, single threaded. Cannot handle multiple requests.
- virtual Crypto Modules shall be included as part of the Guest OS stack, replacing hardware with virtual modules, maybe using VIRTIO
Hardware will initiate some unique random number, that cannot be copied. Needed in multiple VMs
Sang-bum: we need to get feedback from Car manufacters what is the desired configuration.
Gunnar: we might need to anticipate it, with some use cases.
Dmitry: not my area of expertise
Gunnar: we might need to reach out for experts from each company. Or what is the proper way to deal with this.
Franz: no feedback to the topic. Could probably try to get some internal feedback. Security is a big topic as of now. Every customer seems to have different ideas.
Gunnar: This should be the case, since there seems to be a consensus on which is a suitable security feature. But we don't want to go around in circles.
Franz: Security Group within Genivi?
Gunnar: not at this stage.
Franz: we need to summarise the discussion in order to be presented to other company members.
Vasco: also from me, no expertise in this area.
Sang-bum: We need to refer to the OEMs
Gunnar: This is important but we should not allow it to be a blocker. (Each company here has experience about systems] ; blocking might delay the discussion.
Sang-bum: we need to look at the whole system architecture, not stay limited to some component, because we are not experts in all the components.
## Updates from Embedded World
Stephen: Renesas announced RH850 microcontrollers with hypervisor support:
www.renesas.com/eu/en/about/press-center/news/2019/news20190225.html. Focusing on classic or adaptive Autosar.
Block Diagram www.renesas.com/eu/en...6.html
Bernhard: ST presented something similar at Embedded World. www.st.com/content/st_com/en/about/media-center/press-item.html/p4141.html
February 26th, 2019
Participants:
Apologies:
Minutes:
VIRTIO for "non-virtual" interfaces
This idea concerns communication between operating systems, especially running on different cores in an soc, with or without a hypervisor.
Kai: for example classic autosar rtos owning an ethernet connection running on smaller dedicated cpu core. ethernet connection can be exposed to multimedia cores using virtio network queues.
...idea extended? block devices? what else?
...needs an interface that exposes addresses, so that knows where to fetch the ethernet frames. i.e. shared memory, i.e. physical addresses
Matti: are you usingn openAMP for this?
...you could use virtio protocol also.
Matti: (previous work) Xilinx + mentor published openAMP for this purpose? I think TI showed something like it on Jacinto 6 .
...VIRTIO network device exposed to multimedia processor.
Kai: It ties into Multi-OS integration focus of the AMM
Audio in virtualization
Gunnar: I'd like to get to a conclusion on this topic, based on previous discussions but hopefully new info
...Let's start with, Hypervisor exposes an interface to VMs. What does it look like?
Matti: Let's start with how hardware works. Audio is a continuous bit stream. Hardware usually has multiple channels. Different hardware knows different buffer layouts. The HW walk through buffers in a timed manner. Take out the data and convert to analog audio and play it.
Gunnar: We got pointers before, quite a while ago, from Artem on the implementation support in Xen - including some parts that are in the kernel tree.
...(But we need to bring this up a level, to standards)
Matti: Xen, as far as I understood. It sets buffers, allows you to access PCM streams. Real hardware works typically with plain PCM format. Also virtual hardware usually accept PCM.
The most common model in virtualization:
Emulating Intel sound card, HD97 audio controller. Specify PCM, bit, length, sample rate. Then dump stuff (audio data) in there.
...It's similar for USB audio. You register a couple of buffers. You send data over. (To summarize, meta data + content, much like any other device to be honest). Not that complicated. The only tricky thing is it is timing sensitive.
Gunnar: Yes let's talk about the real time demands, and virtual machines?
Matti: Hardware signals overflow or underflow. Sends interrupts, so that software starts filling buffers.
...But there is often a lot of slack in audio. Fast microcontrollers can nowadays keep up with what human ear allows for.
Gunnar/Matti: ... Human ear allows for up to several tens of milliseconds, at least.
(Brief sidebar on audio/video sync, a.k.a. lip-sync)
Matti: On things like latency, note for example Android compatibility document CDD, has strict audio (timing) requirements.
...(The latencies) are hard to measure and evaluate.
Gunnar: And this would apply also to "virtual hardware"?
Matti: Yes, if you're running Android as a guest, the requirements are there - they are more about pipeline latency all the way to the end user. They are there to guarantee everything,
...you may have an external amplifier on a network like MOST. The whole chain must fulfil the requirements.
... Once all the network delays are considered, the remaining time for virtualization delays is very small.
Gunnar: (OK... standards)
Matti: So, we built a PoC for VIRTIO. We want to send this upstream. Talked to the "guardians" of the specification. We are still finalizing details. Expect to send out first RFCs (to VIRTIO mailing list) in the coming months or so.
...Prepared this with Michael Tsirkin. from RedHat, and others. Relatively positive.
Matti: The PoC has good enough timing for video calls.. We have not measured exact delay.
It is a protocol specification for VIRTIO Audio.
...(From VIRTIO mailing list) Note that Google emulator guys are also looking into audio virtualiztion. Used for Android emulator (development environment). Want to add support to mainline QEMU, to reduce their own maintenance.
(more details, what's in it?)
Matti: Buffer exchange. Define which audio streams can be supported? Discoverable, number of channels, direction, layout, etc. Some hardware prefers certain buffer layouts, certain sample rates, etc. Application should send the right formats.
Gunnar: ... If the hardware cannot process a certain format, it must get what it needs. It is better to do this conversion close to application then? Hypervisor layer should not do processing
Matti: Upsampling is easy - so that could be done. Sample rate conversion with good quality takes more.
...That is often offloaded to DSP or even more specialized hardware.
... So (that hardware) could be used by a Hypervisor to implement some such features.
Gunnar: So we should leave it open how advanced Hypervisor implements processing of audio. This could be unique feature per implementation?
... (Virtual) Device can report its capabilities and it will either be rudimentary or advanced, the guest have to adapt...
Matti: (I'd say so).
...Better hardware support means less interrupts, less waking up the CPU. So hardware could support a deep pipeline, e.g. take MP3 input instead of PCM. But it is complicated and doesn't even save that much battery any longer, so it has mostly been abandoned. It doesn't work well with content protection (DRM) .
Matti/Gunnar: Summarizing: DRM/security is too complex in hardware pipeline, and it gets out-of-date).
Matt S (ARM): ... let's talk a bit more about DRM. How is it covered?
Matti: Yeah, I think those questions are out of scope. ...It's a pure buffer (PCM)
... (and the other details) Precedence, priority, loudness, mixing...
Matti: (Note that) Mixing doesn't fit into the device protocol.
Matt S: Any Focus on Functional safety?
Matti: Yes, but ....
Gunnar: But DRM needs to be in scope, right. At least to protect the unencrypted buffers?
Matti: Audio DRM systems seem to go (protect) until they reach a PCM buffer, because on most systems it is possible to record this final stream in some way anyway.
Gunnar: Guess most protection today focuses on video content.
Matt S: I'd think that Premium Dolby sound is still considered important (to protect)
... I'd like to reach out to Dolby to get their input on the whole discussion.
Matti: That would surely be very appreciated input.
Matt: (for such protection) Key exchange - does it need to be part of the protocol?
...If we have a mean to talk to an end point - we need to make sure the keys are in place. Dolby will probably have a special codec, probably an encrypted stream. When does key exchange happen?
Gunnar: (Agree, at least the occurence of this exchange should be in the protocol, (or explained when it happens).
Gunnar: Then method itself I guess uses standard methods, Diffie-Hellman, etc.
...
Gunnar: OK how to define how we share or pass through DSPs and custom hardware (like codec support and Sample Rate Conversion)
Matti: It is also very hardware specific. What can be done. Some (hardware) allows pass-through of these decoders, some make it very difficult to do so. Some discourage it because they don't have an IOMMU.
...DSP is more likely to be used for post-processing (than for MP3 decoding). It's a power saving feature and not a performance thing.
Gunnar: OK. We discussed earlier meeting if (at least) the method of configuration for pass-through devices can be standardized (across HVs)
... Although it's clear and open in Xen (standard Linux format device trees, for example).
Matti: I agree/confirm that how that device tree is created is proprietary. Until it reaches the guest, things are highly design/implementation specific.
...I think most OSes use a device-tree approach. e.g. some RTOS are using device trees too.
Gunnar: But other OSes have different formats (of DT)?
Matti: Yes. But I think basic structures are fairly similar at least, but I'm not too familiar with other OSes.
Gunnar: So a type of device tree is the specification for pass-through devices? And the creation of it is proprietary.
(consensus)
Wrap-up.
February 19th, 2019
Participants:
Apologies:
Review plan for next meetings
Gunnar: Table has updated status. Let's review...
Crypto -
Input from Sang-Bum?
S-B: Should be included in VIRTIO. There is one chapter...
Artem: Let me share what I know:
That component would be utilized by the guest operating system. The cryptography accelerator components.
...When we are thinking about TPM chips. Those are is single-threaded machines.
...so that's why VIRTIO proposed virtual TPM.
...We haven't seen in the past that this...
...Security cannot be provided for threaded programming support. Virtual crypto, should be discussed.
Artem: For ARM it works like this.
...The execution level of security is higher than the hypervisor. If there is a task running in EL3 it will always have higher priority than hypervisor.
...Therefore, Hypervisor cannot influence what's happening on the secure world.
...Note of course SEL2 implementations coming in next ARM architecture which we talked about efore.
...To implement virtualization support, we have upstreams VM IDs to OPTEE. This is already included. R-Car is supported.
...For the guest on ARM, if OPTEE is used (or any other TEE supporting virt) they will be transparent operationally hardware sharing inside trustzone has to be implemented, again out of control for HV.
...Architecturally I can only explain how that work on current ARM architecture, not Intel.
V8.4 There is the alpha draft of the specification available.
Bernhard: Yes, the one we discussed before. NDA only -- you need to send me an email to request. (ongoing)
Artem: Thus on ARM even with current implementation, HV is out of picture.
...You need to support it in TEE software. You also need to implement sharing on the secure device drivers level.
...The guest will be able to access it directly without virtualization supprot
... HV needs to pass ??? VMID
.. with security policies you may allow or disallow security, trapping some syscalls.
... Intel is probably different
Sang-Bum: It might be true, if sec controlled by ARM SoC hardware
...Running trust zone area. HV only running at normal.
...Before HV applied to ARM, operating system utilize ARM hardwarae, should be embedded within that operating system.
...Applying HV at normal domain, the operating system manage the ARM hardware, also should be run on hardware in some cases.
...HV only has control over ARM hardware, If the other guest operating system
Gunnar: Sang-bum can you put some of these thoughts into writing. (I cannot take notes fast enough)
Sang-Bum: Yes.
Artem: for Embedded, there is a standard called Global Platform. Many trusted execution environments make use of this.
Sang-bum: This is covering trusted execution environments. We can us global platform APIs.
AI(Artem): Provide references go global platform
Planning SBSA timing
12 March: CET 11-12 is OK?
Sang-Bum: Yes, 7PM for me, it is OK
Artem: I might be travelling on 12th... I will know in a few days.
Gunnar: I think this time was generally OK with Anup. I will check.
Sang-Bum: I'm not available next week tuesday, but 5th March is OK.
AI: Where is Global Platform defined?
AI: Gunnar - confirm 11.00 for 12 March
USB Virtualiztion
Gunnar: Let's go through the proposal I wrote based on previous discussions
Artem: Actually I have found more info. Some solutions for virtualized USB exist. I don't yet know if they make sense and are useful or not.
Gunnar: Please provide links.
Artem: I will check (until next week) what is possible with respect to USB virtualization.s
Gunnar: I then ask if the *configuration* of the pass-through can be standardized
Artem: Well at least on Xen it is all defined using device-tree (according to Linux kernel standard).
... Some patches for partial device tree. In other words, HV gets a big one, and splits the pass-through according to some, configuration and injects the results into the guest DTs.
Gunnar: So that is Linux (guest) specific? Just let me ask, for example, Xen runs Windows - how would that work?
Artem: Windows - done with ACPI on Intel at least... I have not looked because I work on ARM and Windows on ARM is...well has a difficult history.
Gunnar: OK, sure, but let's say FreeRTOS...
Artem: Everything has to be statically configured. We do the configuration at compile-time in that case (compiling the RTOS hardware part)
...Configuration can be passed to other domains
...In smaller RTOS they don't always support injecting a hardware description like device tree so we need to recompile.
Gunnar: Other vendors? Are there different ways to configure this in every hypervisor?
Sang-bum: I think it's vendor specific. It's hard to follow for example device-tree without licensing concerns (if your software is not GPL licensed)
Gunnar: I think I understand... it might be difficult to reuse major things link device-tree without also reusing the implementation of it.
... but you could write your own specification and implement it?
Sang-bum: I don't think we need to discuss a standard specification for how hardware is integrated. It is a kind of implementation detail.
Gunnar: How is it done in OpenSynergy, if you want to share that detail...
Dmitry: I think some XML based configuration files. And special compiler to capture this input. I agree this is implementation specific
Gunnar: OK, statement about this being proprietary is basically correct. I might stillrewrite it a bit based on this input.
Kai: I have sent a proposal for talk at AMM. Idea: VIRTIO might be used to get operating system interaction also when running on bare hardware.
(What follows is a discussion (on overtime) between Artem and Kai about this idea. We expect more interesting discussion on this.)
Kai: consider different operating systems running on different (dedicated) cores. E.g. RTOS on a small core.
Artem: With this idea, sharing hardware between real-time and non-real time domain worries me.
Kai: I meant this, you can use VIRTIO protocol to exchange between domains.
Artem: OK, but you don't need the whole VIRTIO then. There are often hardware mailboxes for example, as alternative (to virtqueues)
Kai: Think about for example VIRTIO NET.
February 12th, 2019
Participants:
Agenda:
Minutes:
February 5, 2019
Participants:
apologies
Agenda:
Minutes:
Fosdem tracks - recommended readings
virtualization and IaaS track - look in particular at
Software Defined Networking track - look in particular at
January 29, 2018
Participants:
Minutes
Reviewing Virtual Device Categories table. No progress. We need to clarify VM responsibilities.
Also we need to convince people from OEMs to participate. We need requirements in general regarding usage of hypervisors in automotive.
From interest to participation. Gunnar introduces the Project description: a high level idea of requirements and respective solutions. OCI as an example. Everyone is welcome to read and give some feedback. Franz asks about the list of VMs (OSes) we want to support. Gunnar: Any OSes that are in the scope of automotive industry (for example Linux (multiple variations), Android, QNX, INTEGRITY, AUTOSAR Adaptive).
January 22, 2019
Participants:
Minutes
Minutes
Fairly short sync up on a few topics and planning the work going forward.
Gunnar: I'm thinking of writing a short introduction chapter for SCMI to make the proposal more concrete. Hopefully this sparks feedback and it's an important chapter.
Artem: SCMI is being updated by ARM. So we should take that into account.
I think we should participate in that kind of spec update.
Bernhard joining...
Bernhard: I can find the right contact people for this.
Artem: Is there any updates on security?
...like SEL2 implementation for ARMv8
Artem: For your information we just upstreamed to OPTEE and to TrustZone support for previous architectures.
Bernhard: On the Watchdog topic:
...The SBSA, Server Based Systems Architecture, includes Watchdog info that could be relevant.
...I can find a team from ARM to give more information about this.
Artem: Is SBSA only for enterprise domain?
Bernhard: No we write it independently. It is part of the architecture itself.
Gunnar: I notice Anup's intro text links to an ARM spec on the watchdog part but that linked document seems chip-specific (I mean ARM-architecture
specific). I think for a cross-platform specification we're looking for something slightly different.
Gunnar: Of course wherever we end up seeing platform differences for a feature, that may be an outcome as well
...if common abstraction is not appropriate for some reason. The important thing is to clarify this and document it.
CES:
Some reflections... What was most shown and discussed at CES? (Autonomous vehicles)
and what was the most interesting for you (Gunnar: For me 1000+ people in GENIVI/NAB showcase event. Not the easiest
place for good business discussions (loud) but it's a fun big meetup place at least.). Also, LGE keynote.
Notes from HV meeting 2018-12-11
Gunnar: Did you perform the action to decide on support (or not) for SCMI-for-sensors proposal?
... SCMI being discussed in OpenSynergy
Dmitry: ...comppany working to form an opinion, will come back.
Dmitry: It seems to be more features on backends side clocks and power domains
...Is SCMI an appropriate protocol
Gunnar: Yes, the specification itself highlights those features. The proposal that this will be repurposed as a standard sensors API is the new idea.
Kai: Not so much focus on that right now
Kai: feedback and a review should be possible
Alex: ... need to give feedback
Alex - noo need for input because EPAM
Gunnar: SCMI - more comments?
Matt: I'd rather have Bernhard comment on it.
Vasco: I need to look into this. Kind of a new topic.
Gunnar: Still open question for me is Intel suppt? I'd consider contacting ACRN project as a start.
Matt: I'd like to think that it can be adopted by Intel, will check if we have had any feedback.
Will check with Bernhard Rill.
Virtualization spec
Dmitry's input:
SHALL/MUST Reuse definitions from VIRTIO
Gunnar: I notice a mix of terms here.
Dmitry: Yes, shall and must are the same thing.
MUST seems to be used as positive and SHALL NOT used as negative (in VIRTIO)
Discussion with Kai on block device
Some features might not be covered by VIRTIO in enough detail.
Kai: trim command is worthwhile to describe.
Gunnar: OK can we then try this as a start - describe trim command in
detail, specification, could be requirements... It should be concrete -
we're writing a specification...
Gunnar: I want to get the AGL review off the backlog, it's been open long
enough. Please read the paper, figure out what is useful / not useful in
the context we are working. Just like source code we should reuse already
done work.... (Just like others may reuse what we produce in the virt
platform spec).
Gunnar: More from backlog - the architecture & requirements work thread has stopped because of lack of input and previous driver Sriram is busy.
Gunnar: Have you looked at this within Bosch? Vasco?
Vasco: I will consider this
- Architecture
- Use case
- Requirements
Gunnar: You can address it from any angle you like of the above 3, it will lead to the kind of results we mean here.
Action (all): AGL paper read through (again), see links
Minutes (TBD)
Participants
Dmitry: I have written 2D and 3D graphics requirements on the Specification draft page.
Reviewing Dmitrys input...
Dmitry: 2D is quite clear
Gunnar: The 2D chapter references VIRTIO 1.0 from 2015. Is it up to date?
Dmitry: Yes, I think so. Not much change (in 2D area)
Dmitry: VIRTIO-VIRGL - empty reference for now. There is no spec to point to yet. I can only refer to kernel source etc.
...hope to see something coming here.
Gunnar: Great start, comprehensive and detailed work!
Gunnar: But it is very minimalistic, which we want of course, but maybe too much.
... We need to write each topic/chapter names so that people can see what each requirement is about.
Dmitry: OK, I will fix that
Gunnar: We should also write some introduction text to topics. Put in a paragraph or so at least. If a particular topic is not covered in VIRTIO remember that we still need to put a placeholder title in there.
Gunnar: Asking the group generally: usefulness of specification? Are we still doing the right thing?
Franz: In some areas PikeOS has its own APIs and we do not use VIRTIO
Gunnar: Understood, and that's a choice anyone is free to make. To be clear we're not saying everything must be exactly according to VIRTIO, but of course other proposals must be laid out if they are going to affect standards work.
...Going through the table to review last week's discussion.
Gunnar. USB (repeat) Any device role? Device role? Anyone?
Gunnar: What are the use cases, you all work in real projects so you are the ones that might know of any.
Franz: I see mostly connection mobile phone, provide streaming video via hone.
Gunnar: That is normally still car in host role and phone in device role I believe.
Gunnar: Anyone else know of any case where car has device-role?
(none answered)
Gunnar: Artem, Updates?
Artem: Sorry been travelling. Will be more up to date next week.
Vasco (chat): Have to drop off...
Going through the table a bit more. Mostly we need to collect and consolidate what has already been created.
Gunnar: Bernhard, updates or thoughts? Your ARM colleagues have provided good input the last few weeks, for example about what lies in the future, i.e. what's still open topics in virtualization.
Bernhard: Sorry, back from vacation, also need to catch up on notes first.
Gunnar: OK, no problem. Let's reconvene next week with more energy. We now have a good draft that will lead the way for other topics.
iteration on the following wiki page content
Tuesday October 16, 2018
Participants
Apologies
Minutes
Quick de-brief
Gunnar: Questions coming up after ARM presentation?
Artem: No immediate questions from me. Julien is main ARM Xen maintainer - he is reviewing the material.
...but it would be interesting if we can come up with a bit more use-cases than the one mentioned in the presentation.
Gunnar: Agreed, I'd like to extend that question to all the HV vendors. Please give your opinion at a later meeting (on where you might like to use the secure execution modes).
Franz: It's generally a good whitepaper. I believe it is quite heavily downloaded also.
Gunnar: Please discuss with all your technical experts in the companies about useage of this, since when we start thinking of usage maybe the ideas we then have will impact the API standards work.
Gunnar: I guess we have crypto listed in our table. That's one, but maybe more.
Artem: Yes, and that is our position [...that cryptography should be implemented in trusted execution environment]. Specifically TEE, should run in the TrustZone mode(s).
Gunnar: Going through the table to see where we stand. Are all topics being covered.
...can we bring any to some final conclusion.
... vIOMMU.
Dmitry: some code proposals but for various reasons it seems it will not make it into mainline Linux. Performance is slow. But there are no known use-cases in Automotive?
... CAN
Franz has linked a virtio-can driver
Anup: This is the frontend driver. I believe the backend was implemented in XVisor but was never sent upstream to me.
(more discussion)
Artem: I think we found little need to virtualize. Actual CAN access is typically implemented in another CPU. Perhaps for sniffing / logging purposes [but that's so simple that you don't need a full stack]
Gunnar: Yes, I have also mostly seen designs where there is a separate Vehicle Interface Processor, or at least a separate core on SoC.
Artem / others: The conclusion might be that there is little need to virtualize CAN. USB might be similar but on the other hand it supports virtualization.
Gunnar: Sure and this might be the conclusion... I can imagine some chapters [in a virtual platform specification] would just make this conclusion and perhaps point to some reference (in this case virtio-can) if someone feels the need to go beyond that.
Continued general discussion
Lars: We should pick one or two easy ones and not try to reach the answer for each.
Gunnar: Agree, . I'm asking about them here but mostly it is the intention of going through the list, to see where we stand... to find simpler ones to start with.
Anup: I think watchdog is important and also Random Number Generator. Virtio has a proposal for RNG but not watchdog.
Gunnar: We might discuss RNG under "crypto" but it's not the only usage so let's just add it separately. Everyone, feel free to add to the list!
GPU...
Gunnar: I think we need to get Matti and Nikola together to finalize discussion on the feasibility of 3D API standards. For 2D everyone seemed to agree that VIRTIO should work. For 3D, I think there are nuances we need to cover. It's never all or nothing - we should be able to find some common parts (API and/or code).
9pfs...
Gunnar / Lars / other discussing. It seems we can wrap it up with the conclusion that we don't see a strong use in Auto/Embedded. Gunnar: I'd be fine with that - we should cover the most common systems. I would write an initial "chapter" on this as an example. But that's mostly a "negative" example [i.e. documenting that it is out of scope]. Now we need also find a positive one, which is needed and where the API standard is decided.
Lars: (For Xen) we only needed it to support running containers. I don't think it plays a part in server virtualization since there are so many other network protocols like NFS (and the VMs communicate between each other using those). As soon as you set up networking, any network filesystem protocol works.
Gunnar: My perception is that [in relation to virtio] this is from VM to hypervisor/host, and that only makes sense in Desktop - VirtualBox/VMWare Workstation, etc. As a standard I imagined NFS would be too big/complicated (to use as API to/from a hypervisor)
AI: All participants asked to:
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.
Gunnar adjourned the meeting with the idea that today's discussion was preparing us for getting this done (starting with one or two simple
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
October 9, 2018 - No phone conference because of tech summit
Tuesday October 2, 2018
Participants
Discussing the tech summit
The overall plan for working session is at:
HVWS Workshop Schedule at Bangalore Tech Summit
A few people asked for a more exact agenda...
The first hour (10.30 CEST, if we have calculated correctly)
will be on GPU sharing.
At 11.30 approximately, switch to Security Block with ARM leading. Up to
45 minutes ARM intro/presentation, followed by Q&A / discussion
After that, follow-up topics.
(later in meeting) Kai offered to prepare some presentation on block devices.
Bernhard: What will be the planned for conferencing?
Philippe/Gunnar: Zoom is our assumed default. If we need to change to Skype or Hangout we will let you know. Details will be sent by Philippe.
Bernhard: We would like to have more questions in advance to cover in presentation.
Gunnar: Collecting at the bottom of this page - please add to it!
Artem: We could discuss my questions on implementation of OPTEE and support for virtualization ARMv8 and prior...
Virtual Platform Definition:
Crypto
Gunnar: Can we start HSM discussion by evaluating crypto support topic listed in table? Sang-Bum?
Sang-Bum: I have too many other engagements. I will be busy until 20th October at least. Maybe after that.
Block devices
Gunnar: We have discussed various aspect I'd like to bring down to some concrete results. Let's document it. Is VIRTIO good enough or what is the remaining gap?
Kai: Still investigating more
... but I think VIRTIO is not concrete enough. I think it needs more specialized descriptions
...That's why I want to investigate the TRIM command to see how well it works.
Kai: Persistence mgmt (stack) is not fully sorted out. (Not clear where in the software stack you should do what). What about Transaction/Commit
semantics for storage? Should that (API) be defined?
Gunnar: Experience from XVisor?
Anup: XVisor provides the VIRTIO block device standard and that's about it.
...It's up to each system to decide
... Where/when can dedicated memory per VM be used (pass-through), and where not?
Kai: For cost reason, one chip per VM is usually not realistic
Anup: Agreed.
General
Anup: The virtual platform specification, will it need to define the exact memory layout \[for memory-mapped devices\]? QEMU basically does this...
... some discussion
... conclusion that presumably yes this is needed if a VM is going to be fully portable? Let's return to this question.
Next meeting in 2 weeks, (with the Tech Summit working session in between).
Minutes TBD
Participants:
Apologies:
Agenda:
Minutes:
Participants:
Agenda:
Minutes
Participants:
Apologies:
Agenda:
Minutes
Participants:
Participants:
Apologies:
Agenda:
Minutes
Participants:
Apologies:
Agenda:
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?
Comments From Nikola Velinov on the meeting notes: The shared implementation can serve as a a good reference for identifying the 'Virtual Platform' requirements on the actual virtualized device. It might not be the best approach to have the platform demand the usage of virtio. Rather it would be better if the 'Virtual Platform' defines requirements on the actual virtualized devices and points to the virtio standard as a reference of such in terms of the guest component. Performance for virtio in this case would not be as critical.
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
Agenda:
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.
Frank
Gunnar
Matti
Sang-bum
Agenda:
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
Frank
Nikola
Kai
Philippe
Gunnar
Ralph
Sang-bum
Minutes
for block storage. And it was confirmed.Participants:
Agenda
Text below taken from the newsletter:
GENIVI Announces Schedule for Fall Technical Summit in India
Many will remember that in 2018, GENIVI moved from a two member meeting per
year model to a single, large member meeting in the spring and 1-2 more
regional technical summits in the fall. The details for one of those
summits are nearing completion and GENIVI wants to get this important event
into your calendars immediately.
On 10-11 October, GENIVI will hold a technical summit in Bangalore, India.
The summit will expand on two active projects within the vehicle domain
interaction strategy, notably Graphics Sharing and Hypervisors. The agenda
will be finalized during coming weeks; however, GENIVI has in mind three
primary goals:
* Provide an overview of the GENIVI Alliance, its projects, and recent
deliverables, to an audience that may have not been able to attend recent
member meetings
* To inform and engage a technical audience in the work of our domain
interaction projects starting with Distributed Graphics and Hypervisors
* To equip developers with hands-on experience using APIs, reference
code and supporting documentation so that they can produce software that
delivers solutions needed for domain interaction challenges.
The summit will be held at the Sheraton Grand Hotel at Brigade Gateway and
will begin at 9:00 am on 10 October and end at 4:00 pm on 11 October. A
networking reception will be held at the end of the first day.
Registration for the event will open on 1 August.
Please consider attending this important technical event and should your
organization be interested in sponsoring the event, please contact Karin
Hanson, GENIVI Event Manager for more information on opportunities available
virtio
Process improvement
Participants:
Minutes
Sriram's notes - minor edits and formatting
(Camera use-case an architecture)
Agenda:
Participants:
Apologies:
Minutes
Agenda:
Participants:
Apologies:
Minutes
Agenda:
Participants:
apologies: Matti (Opensynergy)
Minutes
Agenda:
Participants:
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
Participants:
Apologies
Minutes
API standardization
Matti started writing down thoughts. Needs some approval on content
Matti introducing:
Discussion:
Additional thoughts from participants.
Wrapping up
Action Items
No posted minutes
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
Please see the Hypervisor Workshop Schedule at Munich AMM 2018 page for schedule, speakers, participants and meeting minutes.
Further preparations of AMM agenda
Participants
Apologies
Minutes
Participants
Apologies
Minutes
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
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
Participants
Minutes
We simply discussed and filled in the topics under Hypervisor Project. Discussion much driven by Albert and Christoph.
Participants
Minutes
an white paper released by Arm which gives and insight into the architectural updates in Armv8.4 in the Trustzone: https://community.arm.com/processors/b/blog/posts/architecting-more-secure-world-with-isolation-and-virtualization