Read intro below, and/or the preparation work at the bottom of this page. Then look at actual draft spec working Document Work and Release page.
The Automotive Virtualization Platform
...
- Specifications like these are best developed as open specifications and just like open-source code, it should stand on the shoulders of previous work.
It A virtual platform specification should be built upon already published work, where VIRTIO is the most prominent standard we have found, but add to it if this is not enough. It is clear seems that the automotive industry needs to do more and that it may needs to extend some areas. At minimum it should review and bolster support for the parts most needed in the automotive industry, clarify which parts are required vs optional, and this work result should (will) one way or another make sure that different automotive initiatives combine into common agreements.
The project group has discussed and found consensus on how that automotive virtual platform specification should be donecan achieve this:
For an automotive virtualized platform, VIRTIO is primarily a starting point because the defined devices enable running only basic system functionality but lack the multimedia and other although increasing in breadth over time. Participating companies in this Hypervisor Group are also involved in proposing new functionality in future VIRTIO specifications, to cover audio, multimedia, and hardware accelerators and other unique hardware devices often found in automotive environments.
...
- VIRTIO v1.0 specification. VIRTIO is the starting point for our investigation into the definition of an Automotive-Wide virtualization platform
- VIRTIO v1.1 specification
- What's new in VIRTIO 1.1 (presentation 1, presentation 2 FOSDEM 2018 + video)
- Version 1.1 is under development - therefore we should make sure to study the latest proposals – see git master
- Latest development: VIRTIO git master
Evaluation Process for existing specifications (e.g. Evaluation Process for existing specifications (e.g. VIRTIO)
For each topic:
- Discuss and write down the automotive requirements
- Read VIRTIO chapter
- Decide if VIRTIO is appropriate and complete for requirements (Gap Analysis)
- Write down what the industry needs to do to close the gap
...
Virtual Device Categories
The key challenge for defining a shared virtual platform definition is to first identify the various device driver types such a platform must provide, and to evaluate if existing work so far (e.g. VIRTIO) covers what the automotive industry needs:
| Warning | ||
|---|---|---|
| ||
This table is now somewhat outdated and not used to drive the work any longer. |
The key challenge for defining a shared virtual platform definition is to first identify the various device driver types such a platform must provide, and to evaluate if existing work so far (e.g. VIRTIO) covers what the automotive industry needs:
| (Virtual) Device | Explanation | Champion | Completeness / Applicability evaluation
| Comments and discussion | Spec complete | Include in draft 1 | Ticket to track completion |
|---|---|---|---|---|---|---|---|
| Block Storage | Flash/Disk/persistent storage | Kai |  | Included also automotive persistence requirements. | ready for review | Yes |
Champion
+ interested people
Completeness / Applicability evaluation
Kai
Possibly definition not enough since it is very generic. What happens below when the challenges
Kai working on evaluating these details. Let's investigate practical implementation of TRIM command, as example.| Network | Access to (shared) physical ethernet and guest-to-guest communication |
Need volunteer to write chapter
As far as I can understand, VIRTIO should suffice.Done initial browsing of the specification. Opinions still pending.
Conclusion:
- Follow VIRTIO
- Consoles to VMs are needed during development but should be possible to turn off for production, for security reasons.
(hardware accelerated)
See GPU Summary, VIRTIO GPU Operation Highlights pages
Draft spec – requirements written
Uncertainty (and lots of ongoing development) around 3D APIs - Vulkan progress, etc.
See GPU Summary page
and requirements in spec draft
- for automotive = expanded?
Oct 2018: Input standard being discussed for inclusion in VIRTIO but accepted in principle. Let's wait a few weeks and look at proposal once in VIRTIO.
Mouse/touch events may need to remap coordinates in combined virtual systems but interface may still not be affected by this.
and host (hypervisor)
file systems to the guest. FS=filesystem.
Use-cases: ?
Completeness: Protocol: , VIRTIO spec: (see comment)
Need in Embedded/Automotive: None? Can we find a use-case?
Applicability: For what it does, seems ok. But might not be really needed and therefore "not applicable". Is there something else/more needed?
WIP
Essentially used for "shared folder" capability between host & guest, as in desktop (or maybe some server) usage. Its applicability to embedded hypervisor usage, in which the "host" is not really being used by itself) seems questionable. What's the use-case?
In VIRTIO spec: A PCI type device can indicate that it is going to use the 9P protocol. The specification also has 9P as a specific separate device type. Other than that, I found no further description of such a device type. The protocol is specified elsewhere and complemented by scattered information regarding the specific implementations (Xen, KVM, QEMU, ...)
The protocol seems proven and supposedly OK for what it does. Possibly more security features needed, depending on use-case. VIRTIO however seems to defer the definition completely to "somewhere else"? At least a reference to a canonical specification would seem appropriate.
It is a minimalistic network file-system protocol. It seems apt for the task. Other network protocols like NFS, SMB/SAMBA etc. would be too heavy. It feels a bit esoteric, and while "reinventing" is bad, in this simple case would not be the worst ever, if VIRTIO had defined something else. Flexibility and security features seem somewhat glossed over. There's basically only "fixed user" or "pass-through" for mapping ownership on files in guest/host.
| Think about writing info how to share a physical network in practice (Create bridge between virtual device and physical) |
| Yes except WiFi - leave comment that it is work in progress) | ||||||||||||
| Console | Text terminal input | Gunnar |
| ready for review | Yes |
| |||||||||
| crypto | Access to cryptographic services (hardware accelerated) | With new features, it is enough. We also added some | Now includes:
|
Discussion part needs cleanup | Yes | ||||||||||
| GPU | Graphics hardware | Matti/Dmitry | See Graphics Virtualization, VIRTIO GPU Operation Highlights pages
| See Graphics Virtualization page and requirements in spec draft |
|
3D: Proposal: include a discussion but requirements are not in Draft. Dmitry Morozov please finish according to this. 3D requirements that are not accepted upstream were dropped. Check status of EDID introduction. | |||||||||
| Input | Traditionally keyboard/mouse/etc - for automotive = expanded? | Matti | Matti | Now part of VIRTIO 1.1 Mouse/touch events may need to remap coordinates in combined virtual systems but interface may still not be affected by this. | | Yes | |||||||||
| vsock | Communication between guest (VM) and host (hypervisor) | | Covered in networking chapter - to be put in its own (sub)chapter. |
| Yes | ||||||||||
Filesystem 9pfs and other | 9P = protocol to expose host (hypervisor) file systems to the guest. FS=filesystem. | Gunnar | Completeness: Protocol: Need in Embedded/Automotive: Applicability: | Links: Virtio 1.0 spec : {PCI-9P, 9P device type}. A note on its documentation/definition not being very precise A set of man pages seemingly defining P9? intro, others QEMU instruction how to set up a VirtFS (P9). |
(cut down chapter, should be OK)
| Yes | ||
| vIOMMU | IOMMU coordinates of DMA devices' | Dmitry | See IOMMU Summary |
page Applicability:
|
→ see comments
ARM is actively working on the specification, more features are coming.
Nested virtualization?nested virtualization - however there are still two levels because applications in guest are used to set up IOMMU (protection between applications) and then the VMs themselves are another level. These levels drive the need for a virtualized IOMMU layer (and/or hardware support for the same) | ARM is actively working on the specification, more features are coming. Nested virtualization? The use of Linux Containers inside a VM was mentioned. That in itself is not really nested virtualization. Namespace-based containers, is just a kernel feature providing separation independent of a hypervisor. However, Kata Containers is an approach to tie Linux containers into a hypervisor layer, making them "fully" virtualized. A theoretical situation arises that involves the use of Kata Containers on a Linux system that itself already runs in a VM. That might constitute an example of nested virtualization, but it was decided that this is not a mainstream idea, possibly not supported or feasible, and in each case likely more trouble than it is worth. "Flattening" the virtualization approach so that all units still run on one hypervisor is a likely outcome. Further research into partitioning methods is likely but for now this falls outside of a mainstream automotive virtual platform definition. We highlighted that Linux containers in their normal namespace based implementation are already a very useful system partition tool and it can be trivially applied also if the Linux kernel runs in a VM. |
TODO
Some info on Linux/Xen code here:
HVWS: Xen input and experience on Audio, Display, Input and TEE
Automotive sensors:
Automotive sensors? Radar/LiDAR/? (or are they separate ECUs?)
Standard embedded sensor (ambient light...)
Some OS have requirements - eg. Android requires orientation sensor.
CPUs/SoCs have "internal" sensors too. Relating to temperature and power mgmt. Some internal control tweaks for power management (core frequency / voltage) are like tiny internal actuators. Virtual access to those? Same or different APIs?
So far, zero feedback on SCMI proposal...
→ Put into spec as proposal and move from there.
Artem proposed that Systems Control Management Interface (SCMI) protocol is flexible and an appropriate abstraction for sensors. It is also appropriate for controlling power-management and related things. The hardware access implementation is according to ARM offloaded to a "Systems Control Processor" but this is a virtual concept. It could be a dedicated core in some cases, perhaps in others not. EPAM/Xen tried out putting code in ARM-TF, to act as this SCP.
SCMI destined (?) to become a ARM-wide standard in a currently fragmented reality.
Upper protocol defined, but could imagine different lower transport. One mailbox-style transport is kind-of defined by ARM spec? Discussion if VIRTIO transport would be appropriate. A "SCMI device" type added to VIRTIO?
Challenges:
- Current situation in ARM is fragmented with many overlapping unique APIs across chip vendors.
- Is this doable also on x86, and is it likely to be adopted?
- Discuss applicability beyond "sensors" and where boundaries are drawn.
Reference:
- Related: ARM SCMI "Platform Design document"
What about PINCTRL, and handling the many multiplexed pins in a modern SoC. Any remaining need for lower-level protocols for accessing/virtualizing hardware?
Abstraction of SoC specifics
DSPs
Tensor processors
TODO
Example Assigning Host USB device to a Guest VM in KVM, here:
https://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest
Draft chapter written – see draft spec.
Which use cases do we want to address?
•USB 2.0 (EHCI controller)
•USB 3.0 (xHCI controllers will replace ECHI)
•USB C
•Host only
•Device Classes:
- Mass storage. Enable use of USB device with volume provider
- Communications (e.g. serial, Ethernet)
- Human interface (e.g. keyboard, mouse)
•On-The-Go (system can function as both USB host and USB device)
•Hot-plug (partial support):
- Static configuration of device “tree”. A device can be plugged into a port. Dynamically detect device type.
- Device tree cannot grow dynamically, i.e. cannot plug in a hub
Other Serial devices?
(Where does LIN, etc. fit in?)
Spec chapter needs to be written.LIN-bus:
- Source code for linux-lin driver (for Linux, not necessarily virtual environment):
- Paper by Czech Technical University & Volkswagen Group Research:
LIN based on SocketCAN → 1. OSADL article, 2. paper (PDF).- The paper concludes that LIN data frames are similar enough to CAN frames that it can reuse CAN software infrastructure (such as the SocketCAN standard). LIN is a serial bus, implemented with a UARTs, and therefore standard UART device drivers would be used. For virtual environments, we can rely on the same conclusions, and therefore refer to the answer given for CAN.
- On the other hand, LIN is most popular for its simplicity / low cost (even lower than CAN) and used in very simple ECUs or to/from input devices like switches, knobs and buttons. On the larger CPU it is likely to be run by a separate dedicated microcontroller, or at least small on-chip CPU core. Therefore it can often be considered out-of-scope for the CPU that implements virtualization.
virtio-can: VIRTIO-based CAN driver
Nikola (TSN)
Need new volunteer to complete it, perhaps from GHS?
The required features are not present in the network virtio devices as of virtio 1.0.
Is this → applicable enough to move into specification as requirements? -->
Must have requirements:
- IEEE 802.1AS compatible egress and ingress timestamps on ethernet frames available in the virtio consumer OS
Good to have:
- IEEE 802.1Q-2011 queue enhancement mechanisms available in the virtio consumer OS
- Interesting read about KVM: https://www.linux-kvm.org/page/Multiqueue
General architectural considerations:
- What if there is more than one consumer of the IEEE 802.1AS defined network timebase on the same system?
Sang-bum
+OpenSynergy with BT experience
May be partly applicable - I could write something here to get us started. - GunnarRandom Number Generator
Very important for embedded systems... Let's see what is there and what we need to do.
Planned SBSA presentation from ARM as a starting point.
But: Need a group review of text (verbose) and consider the comments here on the left. And also VIRTIO parts have not been merged to official spec version. |
TBD. Requirements to be removed? | ||||||
| Audio | Matti | | Some info on Linux/Xen code here: Artem Mygaiev - can this comment be removed? Should it affect the spec? | Information is quite complete. and good understanding written. Needs cleanup to become a proper chapter | Requirement set is NOT ready (merged).
| ||
| Sensors | Automotive sensors: | Artem |
| Artem proposed that Systems Control Management Interface (SCMI) protocol as a flexible and an appropriate abstraction for sensors. It is also appropriate for controlling power-management and related things. The hardware access implementation is according to ARM offloaded to a "Systems Control Processor" but this is a virtual concept. It could be a dedicated core in some cases, perhaps in others not. EPAM/Xen tried out putting code in ARM-TF, to act as this SCP. SCMI destined (?) to become a ARM-wide standard in a currently fragmented reality. Upper protocol defined, but could imagine different lower transport. One mailbox-style transport is kind-of defined by ARM spec? Discussion if VIRTIO transport would be appropriate. A "SCMI device" type added to VIRTIO? Challenges:
Reference:
What about PINCTRL, and handling the many multiplexed pins in a modern SoC. Any remaining need for lower-level protocols for accessing/virtualizing hardware? CPUs/SoCs have "internal" sensors too. Relating to temperature and power mgmt. Some internal control tweaks for power management (core frequency / voltage) are like tiny internal actuators. Virtual access to those? Same or different APIs? Some OS have requirements that must be met by "platform" - eg. Android requires orientation sensor. |
Split out GPIO to separate chapter. Placeholder also for describing HW passthrough (in general) All 3 need another review and cleanup to be complete.
| No requirements possible in draft spec. Possibly some of discussion and future outlook... | |
| Media Acceleration (VPUP, IPU, CODEC) | Hardware support for codec/processing |
→ Dmitry |
| Gunnar AnderssonPlease check status - in VIRTIO mailing list... | Not ready in time. Placeholder referencing currrent proposals. | ||
coprocessors and other | Abstraction of SoC specifics DSPs Tensor processors | Not really in VIRTIO scope | Matti: virtualize functions, not devices. Gunnar: Analysis might extract some functions out of these... | (not sure yet if we expect to cover it) | | ||
| USB | Example Assigning Host USB device to a Guest VM in KVM, here:https://www.linux-kvm.org/page/USB_Host_Device_Assigned_to_Guest | Which use cases do we want to address? •USB 2.0 (EHCI controller)
•On-The-Go (system can function as both USB host and USB device)
|
| placeholder for future | |||
Other Serial devices? ... and LIN bus |
| LIN-bus:
UARTs are normally passed through (VM has access to memory mapped hardware) or forwarded (hardware access is done by HV and some abstract interface provided to the VMs) = virtio-console standard. PL011 = ARM fast model UART controller, reference implementation in versatile-express. Provided in RPi and some other hw and virtual platforms. |
Fold discussion into console chapter.
|
emergency-write / early debugging could be left out if we are not done with it. | |||
| CAN |
| virtio-can: VIRTIO-based CAN driver | Decide opinion and write chapter |
Unknown User (anup) - can we summarize again? | |||
| Time Sensitive Networks |
Need new volunteer to complete it, perhaps from GHS? | The required features are not present in the network virtio devices as of virtio 1.0.
| Must have requirements:
Good to have:
General architectural considerations:
| |
Need some more confirmation | ||
| Bluetooth | OpenSynergy with BT experience ? |
| Virtualization of BT hardware might not be required. However, commenting on various system designs seems appropriate. Example: There exists an interface for virtualized audio device (virtio-sound), but Bluetooth is also an audio device (among other things...) What does this mean for how to build an architecture that (for example) uses both virtualization for audio, and bluetooth technologies. |
| Not ready in time for first draft.
| ||
| Memory Balloon Device | Gunnar | In VIRTIO. Applicability to automative is questionable. |
RAM device is being discussed as a better solution later on. | TODO | Not strictly necessary in the first draft version | ||
Random Number Generator | | Covered in the Crypto chapter. | | | |||
| Watchdog | Very important for embedded systems... Let's see what is there and what we need to do. | SBSA has a generic interface, it should be the closest one. Aim for simple interface. Avoid VIRTIO/virt-queue type solution... |
|
|
All related JIRA Tickets
| Jira | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
...
VIRTIO-defined devices
The VIRTIO 1.0 specification is organized a bit differently, and more generic than our detailed list above. Here is a much abbreviated table of contents for VIRTIO 1.0, just to give an overview on the most important parts. Consider, especially, the limited types of devices. All defined devices are under these categories only for the 1.0 version.
...