...
- Definition of the virtual platform...
- virtio as specified, and/or looking at defacto implementations e.g. in Linux
- there are feature flags in the virtio spec - define which ones should be mandatory for automotive use case
- Then guests can be developed against this virtual platform – possible to run guest on any HV that fulfils the platform
- It's like "Virtual appliances" used to be a popular concept. Now containers/applications-containers, same principle.
- Package certain software as a machine image. Deploy to cloud.
- Before virtualization "appliance" is a box of where the software is running, then virtual-appl.
- This work in GENIVI could specify such a baseline environment that describes the set of devices.
- Can be done by referencing existing standards.
- Agreeing on the subset of features that automotive requires - what is mandatory instead of optional.
- Example: The discard capability of the block device. Is optional in virtio, but for embedded, this should be mandatory.
- Discard = Hinting to a flash device that something is not being used anymore.
Discussion:
- Nikola: Virtio standardizes a restricted set of devices only, e.g. GPU(?), what about the devices that are still in draft status.
- Matti: One option is to drive the virtio standards forward (to fill those gaps)
... the other is to just say we shall be compatible with current implementation (in Linux) - Nikola: agrees with Matti's proposal
- Nikola: I'm interested in how to ensure compatibility/compliance to what we define.
- Gunnar: Driving virtio from draft to specific ("work upstream"), specify gaps, and promote that we support a particular defacto defintion. All of those activities help drive standards forward.
- Matti: Plugfests is an option, such as has been done for Bluetooth. (for ensuring compatibility, and also driving standards forward)
- Kai: How much functionality should go into (virtio) driver vs (low-level) device driver part.
- Kai: How to handle non-open implementations (hardware specific low-level driver) etc.?
- Matti: VirtIO should abstract those details typically. We should help to define that.
- Kai: HVs allow for Central device driver management which is useful, it can enforce certain policies.
- Matti: I agree. Example: block-write rate limiting
- Sriram: What about Type 1 vs Type 2. For example using KVM, having a full Linux kernel can be very useful. Also . Type 2 approach enables more possibilities that bare metal
implementation. Also look at Xen. Why don't we look at those. Maybe also go back to requirements :first. - Gunnar: All of those technologies are also represented in our group, (and some might even consider themselves to be their own type). [Thin layer HV and RTOS based, etc.]
Virtual Open Systems work on KVM for example, and others are strong on Xen. I don't right now see a reason to limit to one onlytype. - Several: Requirements can help clarify what is needed.
- Gunnar: I think we should drive those things forward also. I called it a separate workstream but I don't want to create boundaries. I think these things are very related. The only thing is, we won't stop one track (API standards) that we already started, in order to go back to the foundation. I think we can progress this in parallel now.
- Sriram: I have some use cases I'm thinking about, I could write them down.
Additional thoughts from participants.
Wrapping up
Action Items
- Nikola study and summarize AGL whitepaper, in particular looking for basis for defining "the virtual platform", and of course requirements, use-cases, etc. Use Wiki page to summarize.
- Sriram - Write down cases / concrete architecture examples / specific challenge (such as, audio startup&latency in a particular architecture)
May 15
No posted minutes
May 8
...