...
- 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 to of this is the erase of blocks. The resp. 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.
Erase, Write Zeroes, Trim, Discard...
3.1.x Meeting automotive persistence requirements
Comments on the above, according to previous discussions1) Ability to write some specific data items, for which it is guaranteed to be stored (within reasonable and bounded time),
i.e. "Write Through mode" (seen from the perspective of the user space program in the guest) while the majority of data is written in "Cached mode"
(Optionally: Ability to do this using file system, i.e. mount something which guarantees this on a VFS path)
2) Data integrity in case of sudden power loss
3) Flash lifetime (read/write cycle maximums) guarantees (e.g. 10-15 years)
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.
VIRTIO should be sufficient in combination with the right requests being made from user space programs (and running appropriate hardware devices below).
With VIRTIO: option 1 - device is in write-through mode (WCE = on, set per-device in VIRTIO block device)
option 2 - device has WCE = off → BLK_WRITE followed by BLK_SYNC in driver. Possible on a raw block device from user space - open device with OSYNC.
For filesystem it is file system dependent which O-option (and only some guarantee to respect it 100%)
Linux API create a block request. One of the flags in the request is FUA.
Conclusion is that VIRTIO does not break the native behavior. Even in the native case it can be somewhat uncertain but VIRTIO does not make it worse.
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?
3.2 Network Device
Standard networks
...