On Thu, 29 Aug 2019 14:52:06 +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 > > v8: > * Make language about using both FUSE_READ/FUSE_WRITE and the DAX > Window clearer [Cornelia] > v7: > * Clarify that the DAX Window is optional and can be used together with > FUSE_READ/FUSE_WRITE requests [Cornelia] > v6: > * Document timing side-channel attacks [Michael] > --- > virtio-fs.tex | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 66 insertions(+) > > diff --git a/virtio-fs.tex b/virtio-fs.tex > index 1ae17f8..158d066 100644 > --- a/virtio-fs.tex > +++ b/virtio-fs.tex > @@ -179,6 +179,62 @@ \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. > + > +The DAX Window is an alternative mechanism for accessing file contents. > +FUSE\_READ/FUSE\_WRITE requests and DAX Window accesses are possible at the > +same time. Providing the DAX Window is optional for devices. Using the DAX > +Window is optional for drivers. > + > +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. This last paragraph is a bit concerning form s390x perspective. In case of a PCI transport the shared memory region is a chunk of PCI memory (and must be contained within the declared bar, as mandated by commit 855ad7af2bd6). The PCI architecture on s390x is at the moment such, that PCI memory *can't be accessed like regular RAM* but specialized instructions have to be used. I've tried to rise concern about this multiple times. Thus the virtio spec would contradict itself a little (at least on s390x). Of course for virtual zPCI devices we can make this work. But including this paragraph in the VIRTIO specification would mean if one were to implement this in HW it would not work for s390. I don't have a anything better to propose, so I intend to vote yes for this. I just wanted to make sure, we all are aware of the consequences. Sorry for bringing this up again so late. Adding Christian and Pierre as cc. Regards, Halil --------------------------------------------------------------------- To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
