* [virtio-dev] [PATCH v8 0/2] virtio-fs: add virtio file system device
@ 2019-08-29 13:52 Stefan Hajnoczi
2019-08-29 13:52 ` [virtio-dev] [PATCH v8 1/2] content: " Stefan Hajnoczi
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Stefan Hajnoczi @ 2019-08-29 13:52 UTC (permalink / raw)
To: virtio-dev
Cc: Miklos Szeredi, Steven Whitehouse, Vivek Goyal,
Dr. David Alan Gilbert, Sage Weil, Michael S. Tsirkin,
Stefan Hajnoczi
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
--
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* [virtio-dev] [PATCH v8 1/2] content: add virtio file system device
2019-08-29 13:52 [virtio-dev] [PATCH v8 0/2] virtio-fs: add virtio file system device Stefan Hajnoczi
@ 2019-08-29 13:52 ` Stefan Hajnoczi
2019-08-29 13:52 ` [virtio-dev] [PATCH v8 2/2] virtio-fs: add DAX window Stefan Hajnoczi
2019-09-09 15:27 ` [virtio-dev] Re: [PATCH v8 0/2] virtio-fs: add virtio file system device Stefan Hajnoczi
2 siblings, 0 replies; 13+ messages in thread
From: Stefan Hajnoczi @ 2019-08-29 13:52 UTC (permalink / raw)
To: virtio-dev
Cc: Miklos Szeredi, Steven Whitehouse, Vivek Goyal,
Dr. David Alan Gilbert, Sage Weil, Michael S. Tsirkin,
Stefan Hajnoczi, Cornelia Huck
The virtio file system device transports Linux FUSE requests between a
FUSE daemon running on the host and the FUSE driver inside the guest.
The actual FUSE request definitions are not duplicated in the virtio
specification, similar to how virtio-scsi does not document SCSI
command details. FUSE request definitions are available here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/fuse.h
This patch documents the core virtio file system device, which is
functional but lacks the DAX feature introduced in the next patch.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
---
v7:
* Rename num_queues to num_request_queues [Cornelia]
* Clarify that endianness is chosen by the guest driver in the
FUSE_INIT message
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]
---
content.tex | 1 +
introduction.tex | 3 +
virtio-fs.tex | 225 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 229 insertions(+)
create mode 100644 virtio-fs.tex
diff --git a/content.tex b/content.tex
index ee0d7c9..c14e953 100644
--- a/content.tex
+++ b/content.tex
@@ -5677,6 +5677,7 @@ \subsubsection{Legacy Interface: Framing Requirements}\label{sec:Device
\input{virtio-input.tex}
\input{virtio-crypto.tex}
\input{virtio-vsock.tex}
+\input{virtio-fs.tex}
\chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
diff --git a/introduction.tex b/introduction.tex
index c96acf9..40f16f8 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -60,6 +60,9 @@ \section{Normative References}\label{sec:Normative References}
\phantomsection\label{intro:SCSI MMC}\textbf{[SCSI MMC]} &
SCSI Multimedia Commands,
\newline\url{http://www.t10.org/cgi-bin/ac.pl?t=f&f=mmc6r00.pdf}\\
+ \phantomsection\label{intro:FUSE}\textbf{[FUSE]} &
+ Linux FUSE interface,
+ \newline\url{https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/fuse.h}\\
\end{longtable}
diff --git a/virtio-fs.tex b/virtio-fs.tex
new file mode 100644
index 0000000..1ae17f8
--- /dev/null
+++ b/virtio-fs.tex
@@ -0,0 +1,225 @@
+\section{File System Device}\label{sec:Device Types / File System Device}
+
+The virtio file system device provides file system access. The device either
+directly manages a file system or it acts as a gateway to a remote file system.
+The details of how the device implementation accesses files are hidden by the
+device interface, allowing for a range of use cases.
+
+Unlike block-level storage devices such as virtio block and SCSI, the virtio
+file system device provides file-level access to data. The device interface is
+based on the Linux Filesystem in Userspace (FUSE) protocol. This consists of
+requests for file system traversal and access the files and directories within
+it. The protocol details are defined by \hyperref[intro:FUSE]{FUSE}.
+
+The device acts as the FUSE file system daemon and the driver acts as the FUSE
+client mounting the file system. The virtio file system device provides the
+mechanism for transporting FUSE requests, much like /dev/fuse in a traditional
+FUSE application.
+
+This section relies on definitions from \hyperref[intro:FUSE]{FUSE}.
+
+\subsection{Device ID}\label{sec:Device Types / File System Device / Device ID}
+ 26
+
+\subsection{Virtqueues}\label{sec:Device Types / File System Device / Virtqueues}
+
+\begin{description}
+\item[0] hiprio
+\item[1\ldots n] request queues
+\end{description}
+
+\subsection{Feature bits}\label{sec:Device Types / File System Device / Feature bits}
+
+There are currently no feature bits defined.
+
+\subsection{Device configuration layout}\label{sec:Device Types / File System Device / Device configuration layout}
+
+All fields of this configuration are always available.
+
+\begin{lstlisting}
+struct virtio_fs_config {
+ char tag[36];
+ le32 num_request_queues;
+};
+\end{lstlisting}
+
+\begin{description}
+\item[\field{tag}] is the name associated with this file system. The tag is
+ encoded in UTF-8 and padded with NUL bytes if shorter than the
+ available space. This field is not NUL-terminated if the encoded bytes
+ take up the entire field.
+\item[\field{num_request_queues}] is the total number of request virtqueues
+ exposed by the device. Each virtqueue offers identical functionality and
+ there are no ordering guarantees between requests made available on
+ different queues. Use of multiple queues is intended to increase
+ performance.
+\end{description}
+
+\drivernormative{\subsubsection}{Device configuration layout}{Device Types / File System Device / Device configuration layout}
+
+The driver MUST NOT write to device configuration fields.
+
+The driver MAY use from one up to \field{num_request_queues} request virtqueues.
+
+\devicenormative{\subsubsection}{Device configuration layout}{Device Types / File System Device / Device configuration layout}
+
+The device MUST set \field{num_request_queues} to 1 or greater.
+
+\subsection{Device Initialization}\label{Device Types / File System Device / Device Initialization}
+
+On initialization the driver first discovers the device's virtqueues. The FUSE
+session is started by sending a FUSE\_INIT request as defined by the FUSE
+protocol on one request virtqueue. All virtqueues provide access to the same
+FUSE session and therefore only one FUSE\_INIT request is required regardless
+of the number of available virtqueues.
+
+\subsection{Device Operation}\label{sec:Device Types / File System Device / Device Operation}
+
+Device operation consists of operating the virtqueues to facilitate file system
+access.
+
+The FUSE request types are as follows:
+\begin{itemize}
+\item Normal requests are made available by the driver on request queues and
+ are used by the device.
+\item High priority requests (FUSE\_INTERRUPT, FUSE\_FORGET, and
+ FUSE\_BATCH\_FORGET) are made available by the driver on the hiprio queue
+ so the device is able to process them even if the request queues are
+ full.
+\end{itemize}
+
+Note that FUSE notification requests are not supported.
+
+\subsubsection{Device Operation: Request Queues}\label{sec:Device Types / File System Device / Device Operation / Device Operation: Request Queues}
+
+The driver enqueues normal requests on an arbitrary request queue. High
+priority requests are not placed on request queues. The device processes
+requests in any order. The driver is responsible for ensuring that ordering
+constraints are met by making available a dependent request only after its
+prerequisite request has been used.
+
+Requests have the following format with endianness chosen by the driver in the
+FUSE\_INIT request used to initiate the session as detailed below:
+
+\begin{lstlisting}
+struct virtio_fs_req {
+ // Device-readable part
+ struct fuse_in_header in;
+ u8 datain[];
+
+ // Device-writable part
+ struct fuse_out_header out;
+ u8 dataout[];
+};
+\end{lstlisting}
+
+Note that the words "in" and "out" follow the FUSE meaning and do not indicate
+the direction of data transfer under VIRTIO. "In" means input to a request and
+"out" means output from processing a request.
+
+\field{in} is the common header for all types of FUSE requests.
+
+\field{datain} consists of request-specific data, if any. This is identical to
+the data read from the /dev/fuse device by a FUSE daemon.
+
+\field{out} is the completion header common to all types of FUSE requests.
+
+\field{dataout} consists of request-specific data, if any. This is identical
+to the data written to the /dev/fuse device by a FUSE daemon.
+
+For example, the full layout of a FUSE\_READ request is as follows:
+
+\begin{lstlisting}
+struct virtio_fs_read_req {
+ // Device-readable part
+ struct fuse_in_header in;
+ union {
+ struct fuse_read_in readin;
+ u8 datain[sizeof(struct fuse_read_in)];
+ };
+
+ // Device-writable part
+ struct fuse_out_header out;
+ u8 dataout[out.len - sizeof(struct fuse_out_header)];
+};
+\end{lstlisting}
+
+The FUSE protocol documented in \hyperref[intro:FUSE]{FUSE} specifies the set
+of request types and their contents.
+
+The endianness of the FUSE protocol session is detectable by inspecting the
+uint32\_t \field{in.opcode} field of the FUSE\_INIT request sent by the driver
+to the device. This allows the device to determine whether the session is
+little-endian or big-endian. The next FUSE\_INIT message terminates the
+current session and starts a new session with the possibility of changing
+endianness.
+
+\subsubsection{Device Operation: High Priority Queue}\label{sec:Device Types / File System Device / Device Operation / Device Operation: High Priority Queue}
+
+The hiprio queue follows the same request format as the request queues. This
+queue only contains FUSE\_INTERRUPT, FUSE\_FORGET, and FUSE\_BATCH\_FORGET
+requests.
+
+Interrupt and forget requests have a higher priority than normal requests. The
+separate hiprio queue is used for these requests to ensure they can be
+delivered even when all request queues are full.
+
+\devicenormative{\paragraph}{Device Operation: High Priority Queue}{Device Types / File System Device / Device Operation / Device Operation: High Priority Queue}
+
+The device MUST NOT pause processing of the hiprio queue due to activity on a
+normal request queue.
+
+The device MAY process request queues concurrently with the hiprio queue.
+
+\drivernormative{\paragraph}{Device Operation: High Priority Queue}{Device Types / File System Device / Device Operation / Device Operation: High Priority Queue}
+
+The driver MUST submit FUSE\_INTERRUPT, FUSE\_FORGET, and FUSE\_BATCH\_FORGET requests solely on the hiprio queue.
+
+The driver MUST not submit normal requests on the hiprio queue.
+
+The driver MUST anticipate that request queues are processed concurrently with the hiprio queue.
+
+\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
+more POSIX user ids and group ids. The device has no secure way of
+differentiating between users originating requests via the driver. Therefore
+the device accepts the POSIX user ids and group ids provided by the driver and
+security is enforced by the driver rather than the device. It is nevertheless
+possible for devices to implement POSIX user id and group id mapping or
+whitelisting to control the ownership and access available to the driver.
+
+File systems containing special files including device nodes and setuid
+executable files pose a security concern. These properties are defined by the
+file type and mode, which are set by the driver when creating new files or by
+changes at a later time. These special files present a security risk when the
+file system is shared with another machine. A setuid executable or a device
+node placed by a malicious machine make it possible for unprivileged users on
+other machines to elevate their privileges through the shared file system.
+This issue can be solved on some operating systems using mount options that
+ignore special files. It is also possible for devices to implement
+restrictions on special files by refusing their creation.
+
+When the device provides shared access to a file system between multiple
+machines, symlink race conditions, exhausting file system capacity, and
+overwriting or deleting files used by others are factors to consider. These
+issues have a long history in multi-user operating systems and also apply to
+virtio-fs. They are typically managed at the file system administration level
+by providing shared access only to mutually trusted users.
+
+\subsubsection{Live migration considerations}\label{sec:Device Types / File System Device / Live Migration Considerations}
+
+When a driver is migrated to a new device it is necessary to consider the FUSE
+session and its state. The continuity of FUSE inode numbers (also known as
+nodeids) and fh values is necessary so the driver can continue operation
+without disruption.
+
+It is possible to maintain the FUSE session across live migration either by
+transferring the state or by redirecting requests from the new device to the
+old device where the state resides. The details of how to achieve this are
+implementation-dependent and are not visible at the device interface level.
+
+Maintaining version and feature information negotiated by FUSE\_INIT is
+necessary so that no FUSE protocol feature changes are visible to the driver
+across live migration. The FUSE\_INIT information forms part of the FUSE
+session state that needs to be transferred during live migration.
--
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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [virtio-dev] [PATCH v8 2/2] virtio-fs: add DAX window
2019-08-29 13:52 [virtio-dev] [PATCH v8 0/2] virtio-fs: add virtio file system device Stefan Hajnoczi
2019-08-29 13:52 ` [virtio-dev] [PATCH v8 1/2] content: " Stefan Hajnoczi
@ 2019-08-29 13:52 ` Stefan Hajnoczi
2019-08-29 14:00 ` Cornelia Huck
2019-09-10 12:00 ` Halil Pasic
2019-09-09 15:27 ` [virtio-dev] Re: [PATCH v8 0/2] virtio-fs: add virtio file system device Stefan Hajnoczi
2 siblings, 2 replies; 13+ messages in thread
From: Stefan Hajnoczi @ 2019-08-29 13:52 UTC (permalink / raw)
To: virtio-dev
Cc: Miklos Szeredi, Steven Whitehouse, Vivek Goyal,
Dr. David Alan Gilbert, Sage Weil, Michael S. Tsirkin,
Stefan Hajnoczi
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>
---
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.
+
+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 MAY provide the DAX Window to memory-mapped access to file contents. If present, the DAX Window MUST be shared memory region ID 0.
+
+The device MUST support FUSE\_READ and FUSE\_WRITE requests regardless of whether the DAX Window is being used or not.
+
+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 MAY use both FUSE\_READ/FUSE\_WRITE requests and the DAX Window to access file contents.
+
+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
@@ -207,6 +263,16 @@ \subsubsection{Security Considerations}\label{sec:Device Types / File System Dev
virtio-fs. They are typically managed at the file system administration level
by providing shared access only to mutually trusted users.
+Multiple machines sharing access to a file system are susceptible to timing
+side-channel attacks. By measuring the latency of accesses to file contents or
+file system metadata it is possible to infer whether other machines also
+accessed the same information. Short latencies indicate that the information
+was cached due to a previous access. This can reveal sensitive information,
+such as whether certain code paths were taken. The DAX Window provides direct
+access to file contents and is therefore a likely target of such attacks.
+These attacks are also possible with traditional FUSE requests. The safest
+approach is to avoid sharing file systems between untrusted machines.
+
\subsubsection{Live migration considerations}\label{sec:Device Types / File System Device / Live Migration Considerations}
When a driver is migrated to a new device it is necessary to consider the FUSE
--
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
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [virtio-dev] [PATCH v8 2/2] virtio-fs: add DAX window
2019-08-29 13:52 ` [virtio-dev] [PATCH v8 2/2] virtio-fs: add DAX window Stefan Hajnoczi
@ 2019-08-29 14:00 ` Cornelia Huck
2019-09-10 12:00 ` Halil Pasic
1 sibling, 0 replies; 13+ messages in thread
From: Cornelia Huck @ 2019-08-29 14:00 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: virtio-dev, Miklos Szeredi, Steven Whitehouse, Vivek Goyal,
Dr. David Alan Gilbert, Sage Weil, Michael S. Tsirkin
On Thu, 29 Aug 2019 14:52:06 +0100
Stefan Hajnoczi <stefanha@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 <stefanha@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(+)
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* [virtio-dev] Re: [PATCH v8 0/2] virtio-fs: add virtio file system device
2019-08-29 13:52 [virtio-dev] [PATCH v8 0/2] virtio-fs: add virtio file system device Stefan Hajnoczi
2019-08-29 13:52 ` [virtio-dev] [PATCH v8 1/2] content: " Stefan Hajnoczi
2019-08-29 13:52 ` [virtio-dev] [PATCH v8 2/2] virtio-fs: add DAX window Stefan Hajnoczi
@ 2019-09-09 15:27 ` Stefan Hajnoczi
2019-09-09 15:43 ` Michael S. Tsirkin
2019-09-09 15:48 ` Michael S. Tsirkin
2 siblings, 2 replies; 13+ messages in thread
From: Stefan Hajnoczi @ 2019-09-09 15:27 UTC (permalink / raw)
To: virtio-dev
Cc: Miklos Szeredi, Steven Whitehouse, Vivek Goyal,
Dr. David Alan Gilbert, Sage Weil, Michael S. Tsirkin
[-- Attachment #1: Type: text/plain, Size: 3506 bytes --]
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* [virtio-dev] Re: [PATCH v8 0/2] virtio-fs: add virtio file system device
2019-09-09 15:27 ` [virtio-dev] Re: [PATCH v8 0/2] virtio-fs: add virtio file system device Stefan Hajnoczi
@ 2019-09-09 15:43 ` Michael S. Tsirkin
2019-09-09 15:48 ` Michael S. Tsirkin
1 sibling, 0 replies; 13+ messages in thread
From: Michael S. Tsirkin @ 2019-09-09 15:43 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: virtio-dev, Miklos Szeredi, Steven Whitehouse, Vivek Goyal,
Dr. David Alan Gilbert, Sage Weil
On Mon, Sep 09, 2019 at 05:27:34PM +0200, Stefan Hajnoczi wrote:
> 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
Does not look like github knows how to parse this. Should be:
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/49
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* [virtio-dev] Re: [PATCH v8 0/2] virtio-fs: add virtio file system device
2019-09-09 15:27 ` [virtio-dev] Re: [PATCH v8 0/2] virtio-fs: add virtio file system device Stefan Hajnoczi
2019-09-09 15:43 ` Michael S. Tsirkin
@ 2019-09-09 15:48 ` Michael S. Tsirkin
1 sibling, 0 replies; 13+ messages in thread
From: Michael S. Tsirkin @ 2019-09-09 15:48 UTC (permalink / raw)
To: Stefan Hajnoczi
Cc: virtio-dev, Miklos Szeredi, Steven Whitehouse, Vivek Goyal,
Dr. David Alan Gilbert, Sage Weil
On Mon, Sep 09, 2019 at 05:27:34PM +0200, Stefan Hajnoczi wrote:
> 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
vote started.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [virtio-dev] [PATCH v8 2/2] virtio-fs: add DAX window
2019-08-29 13:52 ` [virtio-dev] [PATCH v8 2/2] virtio-fs: add DAX window Stefan Hajnoczi
2019-08-29 14:00 ` Cornelia Huck
@ 2019-09-10 12:00 ` Halil Pasic
2019-09-10 13:09 ` Dr. David Alan Gilbert
1 sibling, 1 reply; 13+ messages in thread
From: Halil Pasic @ 2019-09-10 12:00 UTC (permalink / raw)
To: Stefan Hajnoczi, Cornelia Huck, Christian Borntraeger
Cc: virtio-dev, Miklos Szeredi, Steven Whitehouse, Vivek Goyal,
Dr. David Alan Gilbert, Sage Weil, Michael S. Tsirkin,
Pierre Morel1
On Thu, 29 Aug 2019 14:52:06 +0100
Stefan Hajnoczi <stefanha@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 <stefanha@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-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [virtio-dev] [PATCH v8 2/2] virtio-fs: add DAX window
2019-09-10 12:00 ` Halil Pasic
@ 2019-09-10 13:09 ` Dr. David Alan Gilbert
2019-09-10 14:23 ` Halil Pasic
0 siblings, 1 reply; 13+ messages in thread
From: Dr. David Alan Gilbert @ 2019-09-10 13:09 UTC (permalink / raw)
To: Halil Pasic
Cc: Stefan Hajnoczi, Cornelia Huck, Christian Borntraeger, virtio-dev,
Miklos Szeredi, Steven Whitehouse, Vivek Goyal, Sage Weil,
Michael S. Tsirkin, Pierre Morel1
* Halil Pasic (pasic@linux.ibm.com) wrote:
> On Thu, 29 Aug 2019 14:52:06 +0100
> Stefan Hajnoczi <stefanha@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 <stefanha@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.
Thanks.
Note this is just specifying the way virtiofs uses the existing
(accepted) shared memory region spec. You can add a CCW transport of
that spec to make it appropriate for 390 if needed.
Dave
> Sorry for bringing this up again so late.
>
> Adding Christian and Pierre as cc.
> Regards,
> Halil
>
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [virtio-dev] [PATCH v8 2/2] virtio-fs: add DAX window
2019-09-10 13:09 ` Dr. David Alan Gilbert
@ 2019-09-10 14:23 ` Halil Pasic
2019-09-10 14:31 ` Dr. David Alan Gilbert
0 siblings, 1 reply; 13+ messages in thread
From: Halil Pasic @ 2019-09-10 14:23 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: Stefan Hajnoczi, Cornelia Huck, Christian Borntraeger, virtio-dev,
Miklos Szeredi, Steven Whitehouse, Vivek Goyal, Sage Weil,
Michael S. Tsirkin, Pierre Morel1
On Tue, 10 Sep 2019 14:09:20 +0100
"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> * Halil Pasic (pasic@linux.ibm.com) wrote:
> > On Thu, 29 Aug 2019 14:52:06 +0100
> > Stefan Hajnoczi <stefanha@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 <stefanha@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.
>
> Thanks.
>
> Note this is just specifying the way virtiofs uses the existing
> (accepted) shared memory region spec. You can add a CCW transport of
> that spec to make it appropriate for 390 if needed.
>
On s390x we have both CCW and PCI transport. And that makes things even
more complicated.
IMHO specifying that virtiofs uses the existing shared memory
specification like regular RAM conflicts with what is architecturally
possible on s390x when the transport is PCI.
Because the fact that this is memory exposed by a PCI device and
contained within a bar with the current s390 architecture implies that
this memory can not be used as regular RAM but needs to be accessed via
specialized instructions (PCI LOAD, PCI STORE). @Pierre: please confirm
or disprove me.
Of course both simply not doing DAX window on s390 if transport PCI,
or conceptually extending the architecture (for virtual systems) and
making it work in the non s390 way is an option.
And yes for the CCW transport we can do whatever we want. And I think
we do want regular RAM for CCW transport, because architecturally there
is no way a CCW device can expose memory. So we would/will need to build
something virtual. And if we do, we should do it the way it suits us
best.
Regards,
Halil
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [virtio-dev] [PATCH v8 2/2] virtio-fs: add DAX window
2019-09-10 14:23 ` Halil Pasic
@ 2019-09-10 14:31 ` Dr. David Alan Gilbert
2019-09-25 10:38 ` Michael S. Tsirkin
0 siblings, 1 reply; 13+ messages in thread
From: Dr. David Alan Gilbert @ 2019-09-10 14:31 UTC (permalink / raw)
To: Halil Pasic
Cc: Stefan Hajnoczi, Cornelia Huck, Christian Borntraeger, virtio-dev,
Miklos Szeredi, Steven Whitehouse, Vivek Goyal, Sage Weil,
Michael S. Tsirkin, Pierre Morel1
* Halil Pasic (pasic@linux.ibm.com) wrote:
> On Tue, 10 Sep 2019 14:09:20 +0100
> "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
>
> > * Halil Pasic (pasic@linux.ibm.com) wrote:
> > > On Thu, 29 Aug 2019 14:52:06 +0100
> > > Stefan Hajnoczi <stefanha@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 <stefanha@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.
> >
> > Thanks.
> >
> > Note this is just specifying the way virtiofs uses the existing
> > (accepted) shared memory region spec. You can add a CCW transport of
> > that spec to make it appropriate for 390 if needed.
> >
>
> On s390x we have both CCW and PCI transport. And that makes things even
> more complicated.
>
> IMHO specifying that virtiofs uses the existing shared memory
> specification like regular RAM conflicts with what is architecturally
> possible on s390x when the transport is PCI.
OK.
> Because the fact that this is memory exposed by a PCI device and
> contained within a bar with the current s390 architecture implies that
> this memory can not be used as regular RAM but needs to be accessed via
> specialized instructions (PCI LOAD, PCI STORE). @Pierre: please confirm
> or disprove me.
>
> Of course both simply not doing DAX window on s390 if transport PCI,
> or conceptually extending the architecture (for virtual systems) and
> making it work in the non s390 way is an option.
>
> And yes for the CCW transport we can do whatever we want. And I think
> we do want regular RAM for CCW transport, because architecturally there
> is no way a CCW device can expose memory. So we would/will need to build
> something virtual. And if we do, we should do it the way it suits us
> best.
Yes; I'm assuming you'd do whatever is appropriate on CCW and just not
use DAX with virtio-fs on a PCI transport.
Dave
>
> Regards,
> Halil
>
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [virtio-dev] [PATCH v8 2/2] virtio-fs: add DAX window
2019-09-10 14:31 ` Dr. David Alan Gilbert
@ 2019-09-25 10:38 ` Michael S. Tsirkin
2019-10-09 10:13 ` Cornelia Huck
0 siblings, 1 reply; 13+ messages in thread
From: Michael S. Tsirkin @ 2019-09-25 10:38 UTC (permalink / raw)
To: Dr. David Alan Gilbert
Cc: Halil Pasic, Stefan Hajnoczi, Cornelia Huck,
Christian Borntraeger, virtio-dev, Miklos Szeredi,
Steven Whitehouse, Vivek Goyal, Sage Weil, Pierre Morel1
On Tue, Sep 10, 2019 at 03:31:45PM +0100, Dr. David Alan Gilbert wrote:
> * Halil Pasic (pasic@linux.ibm.com) wrote:
> > On Tue, 10 Sep 2019 14:09:20 +0100
> > "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> >
> > > * Halil Pasic (pasic@linux.ibm.com) wrote:
> > > > On Thu, 29 Aug 2019 14:52:06 +0100
> > > > Stefan Hajnoczi <stefanha@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 <stefanha@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.
> > >
> > > Thanks.
> > >
> > > Note this is just specifying the way virtiofs uses the existing
> > > (accepted) shared memory region spec. You can add a CCW transport of
> > > that spec to make it appropriate for 390 if needed.
> > >
> >
> > On s390x we have both CCW and PCI transport. And that makes things even
> > more complicated.
> >
> > IMHO specifying that virtiofs uses the existing shared memory
> > specification like regular RAM conflicts with what is architecturally
> > possible on s390x when the transport is PCI.
>
> OK.
>
>
> > Because the fact that this is memory exposed by a PCI device and
> > contained within a bar with the current s390 architecture implies that
> > this memory can not be used as regular RAM but needs to be accessed via
> > specialized instructions (PCI LOAD, PCI STORE). @Pierre: please confirm
> > or disprove me.
> >
> > Of course both simply not doing DAX window on s390 if transport PCI,
> > or conceptually extending the architecture (for virtual systems) and
> > making it work in the non s390 way is an option.
> >
> > And yes for the CCW transport we can do whatever we want. And I think
> > we do want regular RAM for CCW transport, because architecturally there
> > is no way a CCW device can expose memory. So we would/will need to build
> > something virtual. And if we do, we should do it the way it suits us
> > best.
>
> Yes; I'm assuming you'd do whatever is appropriate on CCW and just not
> use DAX with virtio-fs on a PCI transport.
>
> Dave
So the TC voted for the current proposal, accordingly I merged
these patches. David, Stefan, Halil, would one of you be willing
to add a patch to clarify the DAX behavior for such systems?
> >
> > Regards,
> > Halil
> >
> >
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [virtio-dev] [PATCH v8 2/2] virtio-fs: add DAX window
2019-09-25 10:38 ` Michael S. Tsirkin
@ 2019-10-09 10:13 ` Cornelia Huck
0 siblings, 0 replies; 13+ messages in thread
From: Cornelia Huck @ 2019-10-09 10:13 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Dr. David Alan Gilbert, Halil Pasic, Stefan Hajnoczi,
Christian Borntraeger, virtio-dev, Miklos Szeredi,
Steven Whitehouse, Vivek Goyal, Sage Weil, Pierre Morel1
[a bit late to the party, sorry]
On Wed, 25 Sep 2019 06:38:53 -0400
"Michael S. Tsirkin" <mst@redhat.com> wrote:
> On Tue, Sep 10, 2019 at 03:31:45PM +0100, Dr. David Alan Gilbert wrote:
> > * Halil Pasic (pasic@linux.ibm.com) wrote:
> > > On Tue, 10 Sep 2019 14:09:20 +0100
> > > "Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> > >
> > > > * Halil Pasic (pasic@linux.ibm.com) wrote:
> > > > > On Thu, 29 Aug 2019 14:52:06 +0100
> > > > > Stefan Hajnoczi <stefanha@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 <stefanha@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).
I saw a set of new instructions being introduced in the kernel which
seem to do just that, but I obviously don't know the details.
> > > > >
> > > > > 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.
> > > >
> > > > Thanks.
> > > >
> > > > Note this is just specifying the way virtiofs uses the existing
> > > > (accepted) shared memory region spec. You can add a CCW transport of
> > > > that spec to make it appropriate for 390 if needed.
> > > >
> > >
> > > On s390x we have both CCW and PCI transport. And that makes things even
> > > more complicated.
> > >
> > > IMHO specifying that virtiofs uses the existing shared memory
> > > specification like regular RAM conflicts with what is architecturally
> > > possible on s390x when the transport is PCI.
> >
> > OK.
> >
> >
> > > Because the fact that this is memory exposed by a PCI device and
> > > contained within a bar with the current s390 architecture implies that
> > > this memory can not be used as regular RAM but needs to be accessed via
> > > specialized instructions (PCI LOAD, PCI STORE). @Pierre: please confirm
> > > or disprove me.
> > >
> > > Of course both simply not doing DAX window on s390 if transport PCI,
> > > or conceptually extending the architecture (for virtual systems) and
> > > making it work in the non s390 way is an option.
> > >
> > > And yes for the CCW transport we can do whatever we want. And I think
> > > we do want regular RAM for CCW transport, because architecturally there
> > > is no way a CCW device can expose memory. So we would/will need to build
> > > something virtual. And if we do, we should do it the way it suits us
> > > best.
> >
> > Yes; I'm assuming you'd do whatever is appropriate on CCW and just not
> > use DAX with virtio-fs on a PCI transport.
That's a possibility; I'm not sure what the new pci instructions can do
for us.
Also, we can't do full DAX in Linux on s390 currently anyway; this
would need some work to enable device memory on s390 which is way
beyond the scope of this.
> >
> > Dave
>
> So the TC voted for the current proposal, accordingly I merged
> these patches. David, Stefan, Halil, would one of you be willing
> to add a patch to clarify the DAX behavior for such systems?
At the moment, I don't see a reason for an extra patch here. FWIW, we
have not even architectured shared regions for ccw yet.
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2019-10-09 10:14 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-08-29 13:52 [virtio-dev] [PATCH v8 0/2] virtio-fs: add virtio file system device Stefan Hajnoczi
2019-08-29 13:52 ` [virtio-dev] [PATCH v8 1/2] content: " Stefan Hajnoczi
2019-08-29 13:52 ` [virtio-dev] [PATCH v8 2/2] virtio-fs: add DAX window Stefan Hajnoczi
2019-08-29 14:00 ` Cornelia Huck
2019-09-10 12:00 ` Halil Pasic
2019-09-10 13:09 ` Dr. David Alan Gilbert
2019-09-10 14:23 ` Halil Pasic
2019-09-10 14:31 ` Dr. David Alan Gilbert
2019-09-25 10:38 ` Michael S. Tsirkin
2019-10-09 10:13 ` Cornelia Huck
2019-09-09 15:27 ` [virtio-dev] Re: [PATCH v8 0/2] virtio-fs: add virtio file system device Stefan Hajnoczi
2019-09-09 15:43 ` Michael S. Tsirkin
2019-09-09 15:48 ` Michael S. Tsirkin
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.