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

[Stefan Hajnoczi <stefanha@redhat.com>]

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

Attachment: signature.asc
Description: PGP signature