> Subject: Re: [Patch v4 0/3] Introduce a driver to support host accelerated > access to Microsoft Azure Blob > > On 7/20/21 12:05 AM, Long Li wrote: > >> Subject: Re: [Patch v4 0/3] Introduce a driver to support host > >> accelerated access to Microsoft Azure Blob > >> > >> On Mon, Jul 19, 2021 at 09:37:56PM -0700, Bart Van Assche wrote: > >>> such that this object storage driver can be implemented as a > >>> user-space library instead of as a kernel driver? As you may know > >>> vfio users can either use eventfds for completion notifications or polling. > >>> An interface like io_uring can be built easily on top of vfio. > >> > >> Yes. Similar to say the NVMe K/V command set this does not look like > >> a candidate for a kernel driver. > > > > The driver is modeled to support multiple processes/users over a VMBUS > > channel. I don't see a way that this can be implemented through VFIO? > > > > Even if it can be done, this exposes a security risk as the same VMBUS > > channel is shared by multiple processes in user-mode. > > Sharing a VMBUS channel among processes is not necessary. I propose to > assign one VMBUS channel to each process and to multiplex I/O submitted to > channels associated with the same blob storage object inside e.g. the > hypervisor. This is not a new idea. In the NVMe specification there is a > diagram that shows that multiple NVMe controllers can provide access to the > same NVMe namespace. See also diagram "Figure 416: NVM Subsystem with > Three I/O Controllers" in version 1.4 of the NVMe specification. > > Bart. Currently, the Hyper-V is not designed to have one VMBUS channel for each process. In Hyper-V, a channel is offered from the host to the guest VM. The host doesn't know in advance how many processes are going to use this service so it can't offer those channels in advance. There is no mechanism to offer dynamic per-process allocated channels based on guest needs. Some devices (e.g. network and storage) use multiple channels for scalability but they are not for serving individual processes. Assigning one VMBUS channel per process needs significant change on the Hyper-V side. Long
