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: Re: [virtio-dev] [PATCH v1] VIRTIO_F_IO_BARRIER: use I/O barriers in driver




On 2018年04月28日 10:23, Tiwei Bie wrote:
There will be hardware virtio devices in the future, which
require drivers to use the barriers suitable for I/O devices,
compared with software virtio devices which just require
drivers to use the barriers suitable for CPU cores.

To fix the ordering issue for hardware virtio devices, add
a new feature: VIRTIO_F_IO_BARRIER. When negotiated, driver
will use the barriers suitable for I/O devices.

Signed-off-by: Tiwei Bie <tiwei.bie@intel.com>
---
RFC -> v1:
- Use plural (Stefan);
- Add more details (Stefan);

  content.tex | 14 ++++++++++++++
  1 file changed, 14 insertions(+)

diff --git a/content.tex b/content.tex
index ae5fa4c..a1c09c4 100644
--- a/content.tex
+++ b/content.tex
@@ -5445,6 +5445,13 @@ Descriptors} and \ref{sec:Packed Virtqueues / Indirect Flag: Scatter-Gather Supp
    that drivers pass extra data (besides identifying the Virtqueue)
    in their device notifications.
    See \ref{sec:Virtqueues / Driver notifications}~\nameref{sec:Virtqueues / Driver notifications}.
+  \item[VIRTIO_F_IO_BARRIER(37)] This feature indicates that the device
+  needs the driver to use the barriers suitable for hardware devices.

Users may ask what the specific kinds of barrier here (e.g mmio barrier or dma barrier). Do we need to clarify that?

Thanks

+  Some transports require barriers to ensure devices have a consistent
+  view of memory.  When devices are implemented in software a weaker
+  form of barrier may be sufficient and yield better performance.
+  This feature indicates whether a stronger form of barrier suitable
+  for hardware devices is necessary.
  \end{description}
\drivernormative{\section}{Reserved Feature Bits}{Reserved Feature Bits}
@@ -5460,6 +5467,10 @@ addresses to the device.
A driver SHOULD accept VIRTIO_F_RING_PACKED if it is offered. +A driver SHOULD accept VIRTIO_F_IO_BARRIER if it is offered.
+If VIRTIO_F_IO_BARRIER has been negotiated, a driver MUST use
+the barriers suitable for hardware devices.
+
  \devicenormative{\section}{Reserved Feature Bits}{Reserved Feature Bits}
A device MUST offer VIRTIO_F_VERSION_1. A device MAY fail to operate further
@@ -5473,6 +5484,9 @@ accepted.
  If VIRTIO_F_IN_ORDER has been negotiated, a device MUST use
  buffers in the same order in which they have been available.
+A device MAY fail to operate further if VIRTIO_F_IO_BARRIER
+is not accepted.
+
  \section{Legacy Interface: Reserved Feature Bits}\label{sec:Reserved Feature Bits / Legacy Interface: Reserved Feature Bits}
Transitional devices MAY offer the following:



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