On Thu, Aug 22, 2019 at 01:34:05PM +0200, Cornelia Huck wrote: > On Tue, 13 Aug 2019 14:13:20 +0100 > Stefan Hajnoczi <stefa...@redhat.com> wrote: > > > Describe how shared memory region ID 0 is the DAX window and how > > FUSE_SETUPMAPPING maps file ranges into the window. > > > > Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com> > > --- > > The FUSE_SETUPMAPPING message is part of the virtio-fs Linux patches: > > https://gitlab.com/virtio-fs/linux/blob/virtio-fs/include/uapi/linux/fuse.h > > > > v6: > > * Document timing side-channel attacks [Michael] > > --- > > virtio-fs.tex | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 55 insertions(+) > > > > diff --git a/virtio-fs.tex b/virtio-fs.tex > > index 81adf85..154b043 100644 > > --- a/virtio-fs.tex > > +++ b/virtio-fs.tex > > @@ -178,6 +178,51 @@ \subsubsection{Device Operation: High Priority > > Queue}\label{sec:Device Types / F > > > > The driver MUST anticipate that request queues are processed concurrently > > with the hiprio queue. > > > > +\subsubsection{Device Operation: DAX Window}\label{sec:Device Types / File > > System Device / Device Operation / Device Operation: DAX Window} > > + > > +FUSE\_READ and FUSE\_WRITE requests transfer file contents between the > > +driver-provided buffer and the device. In cases where data transfer is > > +undesirable, the device can map file contents into the DAX window shared > > memory > > +region. The driver then accesses file contents directly in device-owned > > memory > > +without a data transfer. > > + > > +Shared memory region ID 0 is called the DAX window. Drivers map this > > shared > > +memory region with writeback caching as if it were regular RAM. The > > contents > > +of the DAX window are undefined unless a mapping exists for that range. > > Are drivers still free to use FUSE_{READ,WRITE}?
Yes. Will mention it in the next revision.
> > +
> > +The driver maps a file range into the DAX window using the
> > FUSE\_SETUPMAPPING
> > +request. Alignment constraints for FUSE\_SETUPMAPPING and
> > FUSE\_REMOVEMAPPING
> > +requests are communicated during FUSE\_INIT negotiation.
> > +
> > +When a FUSE\_SETUPMAPPING request perfectly overlaps a previous mapping,
> > the
> > +previous mapping is replaced. When a mapping partially overlaps a previous
> > +mapping, the previous mapping is split into one or two smaller mappings.
> > When
> > +a mapping is partially unmapped it is also split into one or two smaller
> > +mappings.
> > +
> > +Establishing new mappings or splitting existing mappings consumes
> > resources.
> > +If the device runs out of resources the FUSE\_SETUPMAPPING request fails
> > until
> > +resources are available again following FUSE\_REMOVEMAPPING.
> > +
> > +After FUSE\_SETUPMAPPING has completed successfully the file range is
> > +accessible from the DAX window at the offset provided by the driver in the
> > +request. A mapping is removed using the FUSE\_REMOVEMAPPING request.
> > +
> > +Data is only guaranteed to be persistent when a FUSE\_FSYNC request is
> > used by
> > +the device after having been made available by the driver following the
> > write.
> > +
> > +\devicenormative{\paragraph}{Device Operation: DAX Window}{Device Types /
> > File System Device / Device Operation / Device Operation: DAX Window}
> > +
> > +The device MUST allow mappings that completely or partially overlap
> > existing mappings within the DAX window.
> > +
> > +The device MUST reject mappings that would go beyond the end of the DAX
> > window.
> > +
> > +\drivernormative{\paragraph}{Device Operation: DAX Window}{Device Types /
> > File System Device / Device Operation / Device Operation: DAX Window}
> > +
> > +The driver SHOULD be prepared to find shared memory region ID 0 absent and
> > fall back to FUSE\_READ and FUSE\_WRITE requests.
>
> Should the _device_ also be prepared that the driver does not use the
> dax window? Likely yes (old drivers etc.); do we need to spell it out?
Yes, will fix in the next revision.
signature.asc
Description: PGP signature
