...
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 |
---|---|---|---|---|---|
Block Storage | Flash/Disk/persistent storage | Kai | TODO | 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 | TODO | ||
Console | Text terminal input | Gunnar |
DONE, please review | Done initial browsing of the specification. Opinions still pending. Conclusion:
| |
crypto | Access to cryptographic services (hardware accelerated) | ||||
GPU | Graphics hardware | Matti/Dmitry | See GPU Summary, VIRTIO GPU Operation Highlights pages
| See GPU Summary page and requirements in spec draft | |
Input | Traditionally keyboard/mouse/etc - for automotive = expanded? | Matti | 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. | ||
vsock | Communication between guest (VM) and host (hypervisor) | What does the team think of this? | |||
9pfs | 9P = protocol to expose host (hypervisor) file systems to the guest. FS=filesystem. | Gunnar | Use-cases: ? Completeness: Protocol: Need in Embedded/Automotive: Applicability: |
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. 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). Example how to set up in Linux system |
OK to be imprecise? |
vIOMMU | IOMMU coordinates of DMA devices' | Dmitry | See IOMMU Summary [OUTDATED] page Applicability:
| 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. | |
Audio | Matti |
TODO | Some info on Linux/Xen code here: HVWS: Xen input and experience on Audio, Display, Input and TEE
| ||||
Sensors | Automotive sensors: | Artem | 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?
| 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:
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? | |
Media Acceleration (VPUP, IPU, CODEC) | Hardware support for codec/processing Abstraction of SoC specifics DSPs Tensor processors | Artem |
TODO
| |||||
USB | Franz | 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)
| ||
Other Serial devices? (Where does LIN, etc. fit in?) | LIN-bus:
| ||||
CAN | Franz | virtio-can: VIRTIO-based CAN driver | |||
Ethernet (incl. AvB/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.
| Must have requirements:
Good to have:
General architectural considerations:
| ||
Bluetooth | Sang-bum +OpenSynergy with BT experience | Is it possible? Needed? | |||
Memory Balloon Device | Gunnar | ||||
Random Number Generator | Although used also for crypto. Look at what VIRTIO proposes. (Discussion should cover hardware-supported random generator, of course). | ||||
Watchdog | 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. |
...
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.
...