[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v8 0/2] virtio-fs: add virtio file system device
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 Does not look like github knows how to parse this. Should be: Fixes: https://github.com/oasis-tcs/virtio-spec/issues/49
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]