On Tue, Jul 20, 2021 at 05:33:47PM +0000, Long Li wrote:

quoted

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:

quoted

quoted

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:

quoted

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.

So it's a slow interface :(

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.

What is the throughput of a single channel as-is?  You provided no
benchmarks or numbers at all in this patchset which would justify this
new kernel driver :(

thanks,

greg k-h