OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[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]