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
signature.asc
Description: PGP signature
