1) Overview
The virtio block device is a virtual block device (ie. disk), instead of placing write and read requests with the actual device, the backend needs to establish the connection. In consequence, read and write requests (and other exotic requests) are placed in the virtio queue, and serviced (probably out of order) by the device except where noted.
write is considered volatile when it is submitted; the contents of sectors covered by a volatile write are undefined in persistent device backend storage until the write becomes stable. A write becomes stable once it is completed and one or more of the following conditions is true:
- neither VIRTIO_BLK_F_CONFIG_WCE nor VIRTIO_BLK_F_FLUSH feature were negotiated, but VIR-TIO_BLK_F_FLUSH was offered by the device;
- the VIRTIO_BLK_F_CONFIG_WCE feature was negotiated and the writeback field in configuration space was 0 all the time between the submission of the write and its completion;
- a VIRTIO_BLK_T_FLUSH request is sent after the write is completed and is completed itself.
In the automotive case, the decision to make data persistent depends also on the platform health status, this is special, as the used block devices are either Nor or Nand flash devices, e.g., QSPI-attached Flash devices or eMMC flash devices. E.g., below a threshold value or above a certain temperature level these devices cannot be used anymore. Hence, the general approach of the virtio should be refined, i.e., specifically tailored to the aforementioned devices. This would yield virtio Nor Flash devices or virtio eMMC devices at the benefit that the essential features could be supported.
Examples of such features a trimming and block erase commands, data refresh reads or the use case of wear-leveling or other data persistence management features hidden inside the virtio blck device machinery.
2) Requirements
Requirements attached to the implementation of emmC usage are found at different levels of detail. A typical requirement to be fulfilled is of the following: The hypervisor eMMC server shall execute block erase commands as triggered by the VM owning the respective block device. This in turn assumes that the VM, resp. GuestOS has a requirement enforcing the implementation of a block erase command, also referred as TRIM. As the eMMC block area is handled as virtio block device from inside the GuestOS this requires implementation of the vritio block device and for lower version than Virtio 1.1, TRIM command must be added as a path.
The hypervisor and the guest operating systems need to follow the Virtio specification for virtio-blk to provide block services to the guest, requirements to drive the implementation can be obtained from there.
[1] http://docs.oasis-open.org/virtio/virtio/v1.0/cs04/virtio-v1.0-cs04.pdf