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: [PATCH v8 0/2] virtio-fs: add virtio file system device

 * Make language about using both FUSE_READ/FUSE_WRITE and the DAX
   Window clearer [Cornelia]

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

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

 * 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

 * Clarify that there are no request ordering guarantees between requests in a
   single queue [vgoyal]
 * Add explanation of FUSE session endianness detection [dgilbert]

 * Remove notifications virtqueue, it's unimplemented and can be added when
   needed [Miklos]
 * Add Security Considerations and Live Migration Considerations sections
 * 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]