...
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. | Yes | |||||||||||
Network | Access to (shared) physical ethernet and guest-to-guest communication | Think about writing info how to share a physical network in practice (Create bridge between virtual device and physical) |
| Yes | |||||||||||
Console | Text terminal input | Gunnar | Yes |
| |||||||||||
crypto | Access to cryptographic services (hardware accelerated) | We also added some | Now includes:
|
Discussion part needs cleanup | Yes | ||||||||||
GPU | Graphics hardware | Matti/Dmitry | See GPU Summary Graphics Virtualization, VIRTIO GPU Operation Highlights pages
| See GPU SummaryGraphics 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:
| 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. |
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? | 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... | |||||||||||
coprocessors and other | Abstraction of SoC specifics DSPs Tensor processors | Matti: virtualize functions, not devices. Gunnar: Analysis might extract some functions out of these... | |||||||||||||
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)
|
| ||||||||||||
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 |
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 |
RAM device is being discussed as a better solution later on. | |||||||||||||
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... |
|
|
...