...
Wifi adds some additional characteristics not used in wired networks : SSID, passwords/authentication, signal strength, preferred frequency...
What are the typical designs for this? Expose WiFi to only one VM and let it act as gateway/router for the others. Or should the WiFi interface be truly sharable (e.g. Ethernet level bridges created in HV so that each VM has its own network device and they all connect to the WiFi connection)?
To do sharing it would be required to have a WiFi controller that can connect to more than one endpoint (Broadcom, Qualcomm, others... have various hardware solutions.) . MAC-VTAB does a kind of mediated passthrough. This is a passthrough of the MAC address used on the VM side?
Xen: Remote wpa-supplicant, on (VM) network level it is as normal.
Alternative: Virtual device emulate full MAC level on the host side.
---> MORE WORK NEEDED!
Automotive networks
...
Limit guest devices' scope to access system memory during DMA (e.g. for a pass-through device).
Enable scatter-gather accesses due to remapping (DMA buffers do not need to be physically-contiguous).
- 2-stage IOMMU support for systems that don't have relevant hardware.
These requirements should probably not go into draft. Dmitry, please decide or rework
Device ID.
REQ-1: The device ID MUST be set according to the requirement in chapter 2.1 in [VIRTIO-IOMMU].
...
Requirement:
* Access to TrustZone and equivalent functions MUST work in the exact same way as for a native system using the standard access methods (SMC calls on ARM, equivalent on Intel).
RPMB
Changes expected because we want to know if VIRTIO will approve proposal.
Discussion
1-2 sentences, just explain. Replay Protected Memory Buffers.
Note: Virtual rpmb recently proposed on VIRTIO mailing list (from Intel)
...
Cryptography acceleration
Requirement
* If the hardware virtual platform implements crypto acceleration, then the virtual platform MUST MAY implement virtio-crypto as specified in chapter 5.9 in [VIRTIO]
(NB This requirement might be a MUST later on, if the hardware is appropriate, and optional for hardware platform platforms that are limited to single-threaded usage or other limitations)
TODO: Please consider if this should be a MUST or a weaker requirement.
TODO: Need to review feature bits in VIRTIO, which ones are mandatory (for typical automotive embedded hardware).
Discussion
VIRTIO-crypto standard seem started primarily for PCI extension cards implementing crypto acceleration, although specification seems generic enough to support future (SoC) embedded hardware.
The purpose of acceleration can be pure acceleration (client has the key) or rather HSM purpose (such as key is hidden within hardware).
The implementation consideration is analogous to the discussion on RNGs. On some ARM hardware these are offered only within TrustZone and in addition the hardware implementation is stateful. It ought to be possible to implement virtio-crypto also by delegation into TrustZone and therefore we require it also on such platforms however it should be understood that parallell access to this feature may not be possible, meaning that this device can be occupied when a guest requests it. This must be considered in the complete system design.To be reviewed one more time with Matti.
6. Supplemental Virtual Device categories
...
