[virtio-dev] Re: [PATCH v8 0/2] virtio-fs: add virtio file system device

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Sep 09, 2019 at 05:27:34PM +0200, Stefan Hajnoczi wrote:
> On Thu, Aug 29, 2019 at 02:52:04PM +0100, Stefan Hajnoczi wrote:
> > v8:
> >  * Make language about using both FUSE_READ/FUSE_WRITE and the DAX
> >    Window clearer [Cornelia]
> > 
> > v7:
> >  * Rename num_queues to num_request_queues [Cornelia]
> >  * Clarify that endianness is chosen by the guest driver in the
> >    FUSE_INIT message [Cornelia]
> >  * Clarify that the DAX Window is optional and can be used together with
> >    FUSE_READ/FUSE_WRITE requests [Cornelia]
> > 
> > v6:
> >  * Clarify that num_queues only counts request queues [Cornelia]
> >  * State that only high priority requests go on the hiprio queue [Cornelia]
> >  * Expand on how endianness works [Cornelia]
> >  * Use "driver" and "device" instead of "guest" and "host" [Michael]
> >  * Explain how setuid files and device nodes can be a security issue [Michael]
> >  * Clarify that security issues with shared file systems involve multiple machines [Michael]
> >  * Document timing side-channel attacks [Michael]
> > 
> > v5:
> >  * Explain multiqueue semantics: no ordering, identical functionality on each queue, one FUSE session state shared between all queues
> >  * Explain how the FUSE session is started with a FUSE_INIT request
> >  * Consistently use "submit" vs "made available" and "complete" vs "used" terminology [Michael]
> >  * Explain endianness [Michael]
> >  * Clarify hiprio vs normal queue usage [Michael]
> >  * Move SHOULD, MUST, etc wording into normative sections [Michael]
> >  * Mention that FUSE_INIT negotiated state needs to be transferred during live migration [Michael]
> >  * State that the DAX window is mapped with writeback caching like RAM [Michael]
> >  * Mention DAX window mapping alignment constraints (they are communicated via the FUSE protocol) [Michael]
> >  * Explain that FUSE_SETUPMAPPING fails when device resources are exhausted and that splitting mappings consumes resources too [Michael]
> >  * Clarify access rules to DAX window - only touch memory that has a mapping establised
> >  * Document that DAX data persistence is achieved via FUSE_FSYNC
> > 
> > v4:
> >  * Clarify that there are no request ordering guarantees between requests in a
> >    single queue [vgoyal]
> >  * Add explanation of FUSE session endianness detection [dgilbert]
> > 
> > v3:
> >  * Remove notifications virtqueue, it's unimplemented and can be added when
> >    needed [Miklos]
> >  * Add Security Considerations and Live Migration Considerations sections
> >    [Michael]
> > v2:
> >  * Clean up core virtio file system device spec
> >  * Add DAX window
> > 
> > These patches add the virtio file system device, which is based on Linux FUSE
> > but includes the DAX window extension.  Similar to virtio-scsi, which
> > transports SCSI commands, virtio-fs transports FUSE requests and the protocol
> > documentation is not duplicated here.
> > 
> > The DAX window allows file contents to be accessed directly from shared memory.
> > This eliminates copying of data, reduces the number of vmexits, and reduces the
> > guest's memory footprint.  It also allows coherent mmap MAP_SHARED semantics
> > between guests on the same host.
> > 
> > Stefan Hajnoczi (2):
> >   content: add virtio file system device
> >   virtio-fs: add DAX window
> > 
> >  content.tex      |   1 +
> >  introduction.tex |   3 +
> >  virtio-fs.tex    | 291 +++++++++++++++++++++++++++++++++++++++++++++++
> >  3 files changed, 295 insertions(+)
> >  create mode 100644 virtio-fs.tex
> 
> Fixes: #49
> (https://github.com/oasis-tcs/virtio-spec/issues/49)
> 
> I propose a vote.
> 
> Stefan

vote started.


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org