...
3.1 Storage (Block Device)
Introduction
When using hypervisor technology data on storage devices needs to adhere to high-level security and safety requirements such as isolation and access restrictions. Virtio and its layer for block devices provides the infrastructure for sharing block devices and establish isolation of storage spaces. This is because, actual device access can be controlled by the hypervisor. However, Virtio favors generality over using hardware-specific features. This is problematic in case of specific requirements w.r.t. robustness and endurance measures often associated with the use of persistent data storage such as flash devices. In this context one can spot three relevant scenarios:
- Features transparent to the GuestOS. For these features, the required functionality can be implemented close to the access point, e.g., inside the actual driver. As an example, one may think of a flash device where the flash translation layer (FTL) needs to be provided by software. This is in contrast to, for example, MMC flash device, SD cards and USB thumb drives where the FTL is transparent to the software.
- Features established via driver extensions and workarounds at the level of the GuestOS. These are features which can be differentiated at the level of (logical) block devices such that the GuestOS use different block devices and the driver running in the backend enforces a dedicated strategy for each (logical) block device. E.g., GuestOS and its application may require different write modes, here reliable vs. normal write.
- Features which call for an extension of the VIRTIO Block device driver standard. Whereas category 1 and 2 does not need an augmentation of the Virtio block device standard, a different story needs to be told, whenever such workarounds do not exist. An example of this is the erase of blocks. The respective commands can only be emitted by the GuestOS. The resulting TRIM commands need to be explicitly implemented in both the front-end as well as in the back-end driven by the hypervisor.
...
- .
3.1.x Meeting automotive persistence requirements
...
NOTE: LUNs (defined in UFS) divide the device into parts, so that a fully-unified-access FUA does not mean all caches should be flushed. eMMC does not provide this. Either NVMe or SCSI or UFS devices are required. You could map partitions onto LUNs (some optimized for write-through and some for better average performance) and build from there.
...
Only thing missing: VIRTIO might not provide the "total blocks written" data that is available in native systems. Arguable if guest needs to know this? Are there preventative measures / diagnostics that would benefit from this?diagnostics that would benefit from this?
3.2 Network Device
Standard networks
...
REQ-1: The device ID MUST be set according to the requirement in chapter 5.7.1 in [VIRTIO-GPU].
---------- > 
CHECK IF CHAPTER NUMBERS ARE VALID FOR VIRTIO 1.1
Virtqueues.
REQ-2: The virtqueues MUST be set up according to the requirement in chapter 5.7.2 in [VIRTIO-GPU].
...
a. The device MUST set reserved to zero.
b. The device SHALL NOT present mo
---------- > CHECK IF CHAPTER NUMBERS ARE VALID FOR VIRTIO 1.1
re more than one VIRTIO_IOMMU_RESV_MEM_T_MSI property per endpoint.
c. The device SHALL NOT present RESV_MEM properties that overlap each others for the same endpoint.
...
[VIRTIO] Virtual I/O Device (VIRTIO) Version 1.01, Committee Specification 0401, release 03 March 2016.20 December, 2018
[VIRTIO-GPU] Virtual I/O Device (VIRTIO) Version 1.0, Committee Specification 03-virtio-gpu, release 02 August 2015.
-→ UPDATE THIS FOR 1.1?
[VIRTIO-VIRGL] [AN OASIS STANDARD PROPOSAL OR OWN PAPER IS NEEDED] https://github.com/Keenuts/virtio-gpu-documentation/blob/master/src/virtio-gpu.md
...