Re: [virtio-dev] [VIRTIO RFC] content: add virtio file system device

[Cornelia Huck <cohuck@redhat.com>]

On Tue, 11 Dec 2018 12:51:56 +0000
Stefan Hajnoczi <stefanha@redhat.com> wrote:

> The work-in-progress virtio file system device transports Linux FUSE
> requests between a FUSE daemon running on the host and the FUSE driver
> inside the guest.
> 
> This is an early version of the spec that maps FUSE requests to
> virtqueues.  No changes are needed to the FUSE request format.
> 
> Multiqueue is supported for normal requests.  FUSE_INTERRUPT and
> FUSE_FORGET requests are only sent on the dedicated hiprio queue.
> Notifications are sent on the notifications queue.
> 
> The FUSE driver currently works in a "pull" model where userspace reads
> requests from /dev/fuse one at a time.  Virtqueues are a "push" model
> where the FUSE driver will need to enqueue requests onto a specific
> virtqueue and wait for the guest to process them.
> 
> The request queue buffers are completed by the device when the request
> has been processed and struct fuse_out_header has been filled out.  The
> FUSE driver then picks up the completed request and processes it as if
> the FUSE daemon had written to /dev/fuse.
> 
> Notifications involve device-to-driver communication.  Since virtqueues
> live in guest RAM, the device cannot initiate communication.  Instead
> the notifications queue is populated with empty buffers by the FUSE
> driver (similar to a NIC rx queue).  The device then "completes" a
> buffer when it wishes to notify the driver.  Replies to the notification
> are place in a normal request queue, they do not go via the
> notifications queue.
> 
> Note that this design assumes that the driver knows the required buffer
> size for each request.  My understanding is that this is true in FUSE.
> The only exception is FUSE_NOTIFY_STORE, and even there the FUSE
> implementation has a limit of 32 pages, which makes for a natural buffer
> size limit for the notifications queue.
> 
> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> ---
> The HTML version of this draft spec is available at
> https://stefanha.github.io/virtio/virtio-fs.html#x1-38800010.
> 
> This is mostly for reference and serious review isn't necessary yet.
> 
> For more information on virtio-fs, see https://virtio-fs.gitlab.io/.
> 
> Once the implementation matures we will send a real VIRTIO spec patch.
> 
>  content.tex      |   3 +
>  introduction.tex |   3 +
>  virtio-fs.tex    | 208 +++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 214 insertions(+)
>  create mode 100644 virtio-fs.tex
> 
> diff --git a/content.tex b/content.tex
> index b101d1b..4d38c5a 100644
> --- a/content.tex
> +++ b/content.tex
> @@ -2528,6 +2528,8 @@ Device ID  &  Virtio Device    \\
>  \hline
>  24         &   Memory device \\
>  \hline
> +26         &   file system device \\

Would it make sense to go ahead and reserve this id now?

> +\hline
>  \end{tabular}
>  
>  Some of the devices above are unspecified by this document,