...
- 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 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 this is the erase of blocks. The resp. 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.
...
The function of providing disk access in the form of a "shared folder" or full disk passthrough is a function that seems to have appeared mostly to support mostly used by desktop virtualization of the type where for example the user wants to run for example Microsoft Windows in combination with a MacOS, or to run Linux by running it in a virtual machine hosted by their another main operating system.
It might serve some purpose also in server virtualization if that also is based on Type-2 hypervisor which is in itself an operating system kernel but also hosting multiple virtualized environment.
For the automotive use case, the working group found little need for this type of setup, although host-to-vm disk sharing, but we summarize the situation here if the need arises for some particular product.
If simply network disk access is the desired feature, then most systems will be able to implement a larger Most systems will be able to accomodate any network disk protocol needs by implementing the network protocol in one or several of the VMs. Typical systems we deal with are large enough to include a more complete and more standard protocol such as NFS within the normal operating system environment that is running in he VM and share storage between them over the (virtual) network they have. In other words, for many use cases it need not be implemented in the hypervisor itself.
[VIRTIO] describes one network disk protocol for the purpose of hypervisor-to-vm storage sharing. The protocol 9pfs is mentioned in two ways: A PCI type device can indicate that it is going to use the 9P protocol. The specification also has 9P as a specific separate device type. There seems to be no definition (or even specific reference) to the protocol itself and it is assumed to be well known by name and possible to find online. The specification is complemented by scattered information regarding the specific implementations (Xen, KVM, QEMU, ...)
REQ X:Y: Implementation of host-to-vm disk sharing using to the 9pfs protocol is optional.
The 9pfs protocol seems proven and supposedly OK for what it does. Possibly more security features are needed, depending on use-case. VIRTIO however seems to defer the definition completely to "somewhere else"? At least a reference to a canonical specification would seem appropriate.
It 9pfs is a minimalistic network file-system protocol that the working group think figures is appropriate for the task. Other network protocols like NFS, SMB/SAMBA etc. would be too heavy. 9pfs however feels a bit esoteric, and while "reinventing" is usually unnecessary there might be an appropriate opportunity to do that here, with a new modern protocol plus, a reference open-source implementation. It ought to take a closer look at flexibility and security seem somewhat glossed over in the current 9pfs description which references only "fixed user" or "pass-through" for mapping ownership on files in guest/host.
Links: Virtio 1.0 spec : {PCI-9P, 9P device type}. Kernel support: Xen/Linux 4.12+ FE driver Xen implementation details
References:
A set of man pages seemingly defining P9? intro, others QEMU instruction how to set up a VirtFS (P9). Example/info how to natively mount a 9P network filesystem, Source code for 9pfs FUSE driver
...