[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] [VIRTIO RFC] content: add virtio file system device
On Wed, Dec 12, 2018 at 10:25:56AM +0100, Cornelia Huck wrote: > 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? Yes. Stefan
Attachment:
signature.asc
Description: PGP signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]