...
The most likely remaining solution, considering that virtualized USB access is not a promoted solution, is that one VM is assigned to be the USB master and provide access to the filesystem (or part of it) by means of VM-to-VM communication. For example, a network file system such as NFS or any equivalent solution could be used.
4.
...
Hardware pass-through
Discussion:
Explain what this means in practice, how it can be done, limitations on what VMs are able/allowed to do. In what extent are pass-through features also in fact abstractions and at what extent does this constitute "direct hardware access".
Requirements:
There is a need to document interactions between hardware parts (and sometimes technically limit VM capability) because of the difficulty for VMs to actually configure hardware correctly without causing issues, (including security/stability problems and other... (Matti, for more details)
5. Special Virtual Device categories
5.x GPIO
Discussion:
Should GPIO be para-virtualized and what would it look like?
Consider... whereas an implementation on a kernel might be able to suspend rescheduling for a while and bit-bang a particular interface, this might break completely when HV is in charge of schedulling.
Conclusion : Requiring that the VM has such scheduling guarantees is not realistic.
-→ Whitepaper topic?
???
- The hypervisor/equivalent shall support configurable pass-through access to a VM for digital general-purpose i/O hardware
?? For digital I/O pins, refer to standard pinmux specification (
need clarification)
?? TODO: I2C, similar low-level buses
5
...
.x Automotive Sensors
Protocol accessDiscussion
Sensors can be handled by a dedicated co-processor or the hypervisor implementation and provide the sensor data through a communication protocol. This essentially offloads the burden of defining a "virtual hardware access" from the VM to the measuring hardware. .
For sensors that are not appropriate to virtualize, please refer to chapter on Hardware Pass Through.
Systems Control Management Interface (SCMI) protocol was not originally defined for the virtual-sensor purpose itself, but describes a flexible and an appropriate abstraction for sensors. It is also appropriate for controlling power-management and related things. The actual 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.
- The hypervisor/equivalent shall use SCMI protocol to expose sensor data from a dedicated sensor subsystem to the virtual machines.
Direct Hardware access
For sensor hardware that shall be processed directly by the operating system it may be necessary to provide physical or virtual hardware access
- The hypervisor/equivalent shall provide configurable pass-through access to a VM for sensor hardware (which category of hardware?)
- The hypervisor/equivalent shall be
For digital I/O pins, refer to standard pinmux specification ( need clarification)
4.x Audio
...
TODO: Reference official SCMI spec.
Remaining details
1) Specifying how to put SCMI over VIRTIO. (can be driven by HV group)
2) IIO (Industrial I/O subsystem) driver is being developed for Linux kernel (coming)
Requirement is PENDING for now for those two reasons.
Requirements
- [PENDING] For sensors that need to virtualized the SCMI protocol SHALL be used to expose sensor data from a sensor subsystem to the virtual machines.
5.x Audio
5.x Media codec
TODO Hardware-assisted codecs
...
TBC No particular info in VIRTIO on this?
TODO: See saved text on minutes page.
54.x.x Random Number Generation
...
56. Supplemental Virtual Device categories
56.x Text Console
Discussion
...
It is also recommended that technical and/or process related countermeasures which ensure there is no way to forget to disable these consoles, are introduced and documented during the development phase.
56.1 Filesystem virtualization
...