From: "Michael S. Tsirkin" <mst@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, Sage Weil <sweil@redhat.com>,
Steven Whitehouse <swhiteho@redhat.com>,
Miklos Szeredi <mszeredi@redhat.com>,
Vivek Goyal <vgoyal@redhat.com>,
"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: [virtio-dev] Re: [PATCH v5 2/2] virtio-fs: add DAX window
Date: Fri, 26 Jul 2019 07:41:57 -0400 [thread overview]
Message-ID: <20190726074048-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <20190726095338.24991-3-stefanha@redhat.com>
On Fri, Jul 26, 2019 at 10:53:38AM +0100, Stefan Hajnoczi 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 <stefanha@redhat.com>
> ---
Are there any security considerations with this memory sharing?
If yes it might be a good idea to add a chapter about that,
and functionality/performance/security tradeoffs involved.
> Note that this depends on the shared memory resource specification
> extension that David Gilbert is working on.
> https://lists.oasis-open.org/archives/virtio-comment/201901/msg00000.html
>
> 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
> ---
> virtio-fs.tex | 45 +++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/virtio-fs.tex b/virtio-fs.tex
> index a9f47ce..2d01a51 100644
> --- a/virtio-fs.tex
> +++ b/virtio-fs.tex
> @@ -170,6 +170,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.
> +
> +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.
> +
> +The driver MUST NOT access DAX window areas that have not been mapped.
> +
> \subsubsection{Security Considerations}\label{sec:Device Types / File System Device / Security Considerations}
>
> The device provides access to a file system containing files owned by one or
> --
> 2.21.0
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2019-07-26 11:42 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-26 9:53 [virtio-dev] [PATCH v5 0/2] virtio-fs: add virtio file system device Stefan Hajnoczi
2019-07-26 9:53 ` [virtio-dev] [PATCH v5 1/2] content: " Stefan Hajnoczi
2019-07-31 9:58 ` Cornelia Huck
2019-08-02 15:49 ` Stefan Hajnoczi
2019-08-05 15:38 ` Cornelia Huck
2019-08-05 17:03 ` Dr. David Alan Gilbert
2019-08-03 21:12 ` Michael S. Tsirkin
2019-08-13 9:07 ` Stefan Hajnoczi
2019-08-13 11:24 ` Michael S. Tsirkin
2019-08-13 15:13 ` Stefan Hajnoczi
2019-08-03 21:21 ` Michael S. Tsirkin
2019-08-13 9:35 ` Stefan Hajnoczi
2019-07-26 9:53 ` [virtio-dev] [PATCH v5 2/2] virtio-fs: add DAX window Stefan Hajnoczi
2019-07-26 11:41 ` Michael S. Tsirkin [this message]
2019-08-12 13:55 ` [virtio-dev] " Stefan Hajnoczi
2019-07-26 12:27 ` [virtio-dev] Re: [PATCH v5 0/2] virtio-fs: add virtio file system device Michael S. Tsirkin
2019-07-26 12:34 ` Dr. David Alan Gilbert
2019-08-12 13:56 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190726074048-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=dgilbert@redhat.com \
--cc=mszeredi@redhat.com \
--cc=stefanha@redhat.com \
--cc=sweil@redhat.com \
--cc=swhiteho@redhat.com \
--cc=vgoyal@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.