On Tue, 11 Dec 2018 12:51:56 +0000
Stefan Hajnoczi <> 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 <>
> ---
> 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,
