[virtio] [PATCH v3 0/6] rework notifications terminology

[virtio] [PATCH v3 0/6] rework notifications terminology

[Halil Pasic]

Abstract 
--------
The terminology around notifications is currently somewhat
fragmented. Unify notifications terminology using available and used
buffer notification consistently for the virtqueue notifications.
Consistent use of the term configuration change notification is of
concern.

Changelog:
---------
v2 -> v3:
* Addressed all comments from the previous round
* Added r-b's

v1 -> v2:
* Addressed Stefan's comments (mostly typos, grammar and inconsistencies).
  Thanks Stefan!
* Rebased onto the current master.

RFC -> v1:
* Devices and the transports PCI and MMIO were omitted.
Now the rework should be complete.
* Addressed review comments and minor changes for the first
three patches. 

Halil Pasic (6):
  notifications: unify notifications wording in core
  notifications: notifications as basic virtio facility
  ccw: map common notifications terminology to ccw
  pci: map common notifications terminology to PCI
  mmio: map common notifications terminology to MMIO
  notifications: update notifications terminology for devices

 cl-os.tex       |    2 +-
 conformance.tex |   10 ++--
 content.tex     |  164 +++++++++++++++++++++++++++++++++++++++++-------------
 packed-ring.tex |   60 +++++++++++---------
 split-ring.tex  |   72 ++++++++++++++----------
 5 files changed, 206 insertions(+), 102 deletions(-)


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] [PATCH v3 1/6] notifications: unify notifications wording in core

[Halil Pasic]

Let us unify the wording when talking about notifications. This change
establishes the terms available buffer notification for what was usually
simply called notification or virtqueue notification in v1.0 and used
buffer notification for what was usually called interrupt.

The term configuration change notification in kept where called so and
consolidated where it's called configuration change interrupt or
similar.

The changes done here are limited to the core part, and don't
conceptually involve neither the transports nor the devices (references
are updated though). Future changes should address these parts.

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
---
v2 -> v3
* Addressed all comments by Connie and Stefan (changed both directions
with the my nonsensical "i.e.'s" that was pointed out by Stefan)
* Added unrelated grammar fix s/writes entry/writes an entry/ (Stefan)
---
 cl-os.tex       |    2 +-
 conformance.tex |    8 +++---
 content.tex     |   26 +++++++++++--------
 packed-ring.tex |   60 ++++++++++++++++++++++++++--------------------
 split-ring.tex  |   72 ++++++++++++++++++++++++++++++++-----------------------
 5 files changed, 96 insertions(+), 72 deletions(-)

diff --git a/cl-os.tex b/cl-os.tex
index da78bf8..fc12cdd 100644
--- a/cl-os.tex
+++ b/cl-os.tex
@@ -2,7 +2,7 @@
 trivial typo
 
 See
-\ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Interrupt Suppression}.
+\ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Used Buffer Notification Suppression}.
 } \\
 \hline
 541 & 11 Oct 2015 & Paolo Bonzini & {virtio-blk: fix typo
diff --git a/conformance.tex b/conformance.tex
index e4efe33..de33396 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -37,10 +37,10 @@ A driver MUST conform to the following normative statements:
 \item \ref{drivernormative:Basic Facilities of a Virtio Device / Message Framing}
 \item \ref{drivernormative:Basic Facilities of a Virtio Device / Virtqueues / The Virtqueue Descriptor Table}
 \item \ref{drivernormative:Basic Facilities of a Virtio Device / Virtqueues / The Virtqueue Descriptor Table / Indirect Descriptors}
-\item \ref{drivernormative:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Interrupt Suppression}
+\item \ref{drivernormative:Basic Facilities of a Virtio Device / Virtqueues / Used Buffer Notification Suppression}
 \item \ref{drivernormative:Basic Facilities of a Virtio Device / Virtqueues / The Virtqueue Available Ring}
 \item \ref{drivernormative:Basic Facilities of a Virtio Device / Virtqueues / The Virtqueue Used Ring}
-\item \ref{drivernormative:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Notification Suppression}
+\item \ref{drivernormative:Basic Facilities of a Virtio Device / Virtqueues / Available Buffer Notification Suppression}
 \item \ref{drivernormative:Basic Facilities of a Virtio Device / Virtqueues / Supplying Buffers to The Device / Updating idx}
 \item \ref{drivernormative:Basic Facilities of a Virtio Device / Virtqueues / Supplying Buffers to The Device / Notifying The Device}
 \item \ref{drivernormative:General Initialization And Device Operation / Device Initialization}
@@ -158,9 +158,9 @@ A device MUST conform to the following normative statements:
 \item \ref{devicenormative:Basic Facilities of a Virtio Device / Message Framing}
 \item \ref{devicenormative:Basic Facilities of a Virtio Device / Virtqueues / The Virtqueue Descriptor Table}
 \item \ref{devicenormative:Basic Facilities of a Virtio Device / Virtqueues / The Virtqueue Descriptor Table / Indirect Descriptors}
-\item \ref{devicenormative:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Interrupt Suppression}
+\item \ref{devicenormative:Basic Facilities of a Virtio Device / Virtqueues / Used Buffer Notification Suppression}
 \item \ref{devicenormative:Basic Facilities of a Virtio Device / Virtqueues / The Virtqueue Used Ring}
-\item \ref{devicenormative:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Notification Suppression}
+\item \ref{devicenormative:Basic Facilities of a Virtio Device / Virtqueues / Available Buffer Notification Suppression}
 \item \ref{devicenormative:Reserved Feature Bits}
 \end{itemize}
 
diff --git a/content.tex b/content.tex
index be18234..9b1f3e1 100644
--- a/content.tex
+++ b/content.tex
@@ -72,7 +72,8 @@ recover by issuing a reset.
 \devicenormative{\subsection}{Device Status Field}{Basic Facilities of a Virtio Device / Device Status Field}
 The device MUST initialize \field{device status} to 0 upon reset.
 
-The device MUST NOT consume buffers or notify the driver before DRIVER_OK.
+The device MUST NOT consume buffers or send any used buffer
+notifications to the driver before DRIVER_OK.
 
 \label{sec:Basic Facilities of a Virtio Device / Device Status Field / DEVICENEEDSRESET}The device SHOULD set DEVICE_NEEDS_RESET when it enters an error state
 that a reset is needed.  If DRIVER_OK is set, after it sets DEVICE_NEEDS_RESET, the device
@@ -235,12 +236,13 @@ transmit and one for receive.}.
 Driver makes requests available to device by adding
 an available buffer to the queue - i.e. adding a buffer
 describing the request to a virtqueue, and optionally triggering
-a driver event - i.e. sending a notification to the device.
+a driver event - i.e. sending an available buffer notification
+to the device.
 
 Device executes the requests and - when complete - adds
 a used buffer to the queue - i.e. lets the driver
 know by marking the buffer as used. Device can then trigger
-a device event - i.e. send an interrupt to the driver.
+a device event - i.e. send a used buffer notification to the driver.
 
 Device reports the number of bytes it has written to memory for
 each buffer it uses. This is referred to as ``used length''.
@@ -330,7 +332,8 @@ set the FAILED status bit to indicate that it has given up on the
 device (it can reset the device later to restart if desired).  The
 driver MUST NOT continue initialization in that case.
 
-The driver MUST NOT notify the device before setting DRIVER_OK.
+The driver MUST NOT send any buffer available notifications to
+the device before setting DRIVER_OK.
 
 \subsection{Legacy Interface: Device Initialization}\label{sec:General Initialization And Device Operation / Device Initialization / Legacy Interface: Device Initialization}
 Legacy devices did not support the FEATURES_OK status bit, and thus did
@@ -388,10 +391,11 @@ reads unless notified.
 
 \subsection{Notification of Device Configuration Changes}\label{sec:General Initialization And Device Operation / Device Operation / Notification of Device Configuration Changes}
 
-For devices where the device-specific configuration information can be changed, an
-interrupt is delivered when a device-specific configuration change occurs.
+For devices where the device-specific configuration information can be
+changed, a configuration change notification is sent when a
+device-specific configuration change occurs.
 
-In addition, this interrupt is triggered by the device setting
+In addition, this notification is triggered by the device setting
 DEVICE_NEEDS_RESET (see \ref{sec:Basic Facilities of a Virtio Device / Device Status Field / DEVICENEEDSRESET}).
 
 \section{Device Cleanup}\label{sec:General Initialization And Device Operation / Device Cleanup}
@@ -5339,7 +5343,7 @@ Virtqueues / The Virtqueue Descriptor Table / Indirect
 Descriptors} and \ref{sec:Packed Virtqueues / Indirect Flag: Scatter-Gather Support}~\nameref{sec:Packed Virtqueues / Indirect Flag: Scatter-Gather Support}.
   \item[VIRTIO_F_RING_EVENT_IDX(29)] This feature enables the \field{used_event}
   and the \field{avail_event} fields as described in
-\ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Interrupt Suppression}, \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / The Virtqueue Used Ring} and \ref{sec:Packed Virtqueues / Driver and Device Event Suppression}.
+\ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Used Buffer Notification Suppression}, \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / The Virtqueue Used Ring} and \ref{sec:Packed Virtqueues / Driver and Device Event Suppression}.
 
 
   \item[VIRTIO_F_VERSION_1(32)] This indicates compliance with this
@@ -5413,16 +5417,16 @@ Transitional devices MAY offer the following:
 \begin{description}
 \item[VIRTIO_F_NOTIFY_ON_EMPTY (24)] If this feature
   has been negotiated by driver, the device MUST issue
-  an interrupt if the device runs
+  a used buffer notification if the device runs
   out of available descriptors on a virtqueue, even though
-  interrupts are suppressed using the VIRTQ_AVAIL_F_NO_INTERRUPT
+  notifications are suppressed using the VIRTQ_AVAIL_F_NO_INTERRUPT
   flag or the \field{used_event} field.
 \begin{note}
   An example of a driver using this feature is the legacy
   networking driver: it doesn't need to know every time a packet
   is transmitted, but it does need to free the transmitted
   packets a finite time after they are transmitted. It can avoid
-  using a timer if the device interrupts it when all the packets
+  using a timer if the device notifies it when all the packets
   are transmitted.
 \end{note}
 \end{description}
diff --git a/packed-ring.tex b/packed-ring.tex
index 2ef9559..ebbad95 100644
--- a/packed-ring.tex
+++ b/packed-ring.tex
@@ -42,8 +42,8 @@ the descriptor.
 The driver then notifies the device. When the device has finished
 processing the buffer, it writes a used device descriptor
 including the Buffer ID into the Descriptor Ring (overwriting a
-driver descriptor previously made available), and sends an
-interrupt.
+driver descriptor previously made available), and sends a
+used event notification.
 
 The Descriptor Ring is used in a circular manner: the driver writes
 descriptors into the ring in order. After reaching the end of the ring,
@@ -65,11 +65,13 @@ in which their processing is complete.
 
 The Device Event Suppression data structure is write-only by the
 device. It includes information for reducing the number of
-device events - i.e. driver notifications to device.
+device events - i.e. sending fewer available buffer notifications
+to the device.
 
 The Driver Event Suppression data structure is read-only by the
 device. It includes information for reducing the number of
-driver events - i.e. device interrupts to driver.
+driver events - i.e. sending fewer used buffer notifications 
+to the driver.
 
 \subsection{Driver and Device Ring Wrap Counters}
 \label{sec:Packed Virtqueues / Driver and Device Ring Wrap Counters}
@@ -309,22 +311,20 @@ in the ring.
 
 \subsection{Driver and Device Event Suppression}
 \label{sec:Packed Virtqueues / Driver and Device Event Suppression}
-In many systems driver and device notifications involve
+In many systems used and available buffer notifications involve
 significant overhead. To mitigate this overhead,
 each virtqueue includes two identical structures used for
 controlling notifications between the device and the driver.
 
 The Driver Event Suppression structure is read-only by the
-device and controls the events sent by the device
-to the driver (e.g. interrupts).
+device and controls the used buffer notifications sent by the device
+to the driver.
 
 The Device Event Suppression structure is read-only by
-the driver and controls the events sent by the driver
-to the device (e.g. IO).
+the driver and controls the available buffer notifications sent by the
+driver to the device.
 
-Each of these Event Suppression structures controls
-both Descriptor Ring events and structure events, and
-each includes the following fields:
+Each of these Event Suppression structures includes the following fields:
 
 \begin{description}
 \item [Descriptor Ring Change Event Flags] Takes values:
@@ -354,7 +354,7 @@ made available/used respectively.
 
 After writing out some descriptors, both the device and the driver
 are expected to consult the relevant structure to find out
-whether an interrupt/notification should be sent.
+whether a used respectively an available buffer notification should be sent.
 
 \subsubsection{Structure Size and Alignment}
 \label{sec:Packed Virtqueues / Structure Size and Alignment}
@@ -463,7 +463,7 @@ When notifying the device, driver MUST set
 \field{next_off} and
 \field{next_wrap} to match the next descriptor
 not yet made available to the device.
-A driver MAY send multiple notifications without making
+A driver MAY send multiple available buffer notifications without making
 any new descriptors available to the device.
 
 \drivernormative{\subsection}{Scatter-Gather Support}{Basic Facilities of a
@@ -579,13 +579,14 @@ The driver MUST perform a suitable memory barrier before the
 \field{flags} update, to ensure the
 device sees the most up-to-date copy.
 
-\subsubsection{Notifying The Device}\label{sec:Basic Facilities
-of a Virtio Device / Packed Virtqueues / Supplying Buffers to The Device / Notifying The Device}
+\subsubsection{Sending Available Buffer Notifications}\label{sec:Basic Facilities
+of a Virtio Device / Packed Virtqueues / Supplying Buffers to The Device
+/ Sending Available Buffer Notifications}
 
 The actual method of device notification is bus-specific, but generally
 it can be expensive.  So the device MAY suppress such notifications if it
-doesn't need them, using the Driver Event Suppression structure
-as detailed in section \ref{sec:Basic
+doesn't need them, using the Event Suppression structure comprising the
+Device Area as detailed in section \ref{sec:Basic
 Facilities of a Virtio Device / Packed Virtqueues / Event
 Suppression Structure Format}.
 
@@ -595,7 +596,7 @@ value before checking if notifications are suppressed.
 \subsubsection{Implementation Example}\label{sec:Basic Facilities of a Virtio Device / Packed Virtqueues / Supplying Buffers to The Device / Implementation Example}
 
 Below is a driver code example. It does not attempt to reduce
-the number of device interrupts, neither does it support
+the number of available buffer notifications, neither does it support
 the VIRTIO_F_RING_EVENT_IDX feature.
 
 \begin{lstlisting}
@@ -651,24 +652,31 @@ if (vq->device_event.flags != RING_EVENT_FLAGS_DISABLE) {
 \end{lstlisting}
 
 
-\drivernormative{\paragraph}{Notifying The Device}{Basic Facilities of a Virtio Device / Packed Virtqueues / Supplying Buffers to The Device / Notifying The Device}
+\drivernormative{\paragraph}{Sending Available Buffer Notifications}
+{Basic Facilities of a Virtio Device / Packed Virtqueues / Supplying
+Buffers to The Device / Sending Available Buffer Notifications}
 The driver MUST perform a suitable memory barrier before reading
-the Driver Event Suppression structure, to avoid missing a notification.
+the Event Suppression structure occupying the Device Area. Failing
+to do so could result in mandatory available buffer notifications
+not being sent.
 
 \subsection{Receiving Used Buffers From The Device}\label{sec:Basic Facilities of a Virtio Device / Packed Virtqueues / Receiving Used Buffers From The Device}
 
 Once the device has used buffers referred to by a descriptor (read from or written to them, or
 parts of both, depending on the nature of the virtqueue and the
-device), it interrupts the driver
+device), it sends a used buffer notification to the driver
 as detailed in section \ref{sec:Basic
 Facilities of a Virtio Device / Packed Virtqueues / Event
 Suppression Structure Format}.
 
 \begin{note}
-For optimal performance, a driver MAY disable interrupts while processing
-the used buffers, but beware the problem of missing interrupts between
-emptying the ring and reenabling interrupts.  This is usually handled by
-re-checking for more used buffers after interrups are re-enabled:
+
+For optimal performance, a driver MAY disable used buffer notifications
+while processing the used buffers, but beware the problem of missing
+notifications between emptying the ring and reenabling used buffer
+notifications.  This is usually handled by re-checking for more used
+buffers after notifications are re-enabled:
+
 \end{note}
 
 \begin{lstlisting}
diff --git a/split-ring.tex b/split-ring.tex
index 2267863..be0cd2f 100644
--- a/split-ring.tex
+++ b/split-ring.tex
@@ -54,7 +54,8 @@ When the driver wants to send a buffer to the device, it fills in
 a slot in the descriptor table (or chains several together), and
 writes the descriptor index into the available ring.  It then
 notifies the device. When the device has finished a buffer, it
-writes the descriptor index into the used ring, and sends an interrupt.
+writes the descriptor index into the used ring, and sends a
+used buffer notification.
 
 \drivernormative{\subsection}{Virtqueues}{Basic Facilities of a Virtio Device / Virtqueues}
 The driver MUST ensure that the physical address of the first byte
@@ -318,44 +319,47 @@ VRING_AVAIL_F_NO_INTERRUPT, but the layout and value were identical.
 A driver MUST NOT decrement the available \field{idx} on a virtqueue (ie.
 there is no way to ``unexpose'' buffers).
 
-\subsection{Virtqueue Interrupt Suppression}\label{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Interrupt Suppression}
+\subsection{Used Buffer Notification Suppression}\label{sec:Basic
+Facilities of a Virtio Device / Virtqueues / Used Buffer Notification Suppression}
 
 If the VIRTIO_F_EVENT_IDX feature bit is not negotiated,
 the \field{flags} field in the available ring offers a crude mechanism for the driver to inform
-the device that it doesn't want interrupts when buffers are used.  Otherwise
+the device that it doesn't want notifications when buffers are used.  Otherwise
 \field{used_event} is a more performant alternative where the driver
-specifies how far the device can progress before interrupting.
+specifies how far the device can progress before a notification is
+required.
 
-Neither of these interrupt suppression methods are reliable, as they
+Neither of these notification suppression methods are reliable, as they
 are not synchronized with the device, but they serve as
 useful optimizations.
 
-\drivernormative{\subsubsection}{Virtqueue Interrupt Suppression}{Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Interrupt Suppression}
+\drivernormative{\subsubsection}{Used Buffer Notification Suppression}{Basic Facilities of a Virtio Device / Virtqueues / Used Buffer Notification Suppression}
 If the VIRTIO_F_EVENT_IDX feature bit is not negotiated:
 \begin{itemize}
 \item The driver MUST set \field{flags} to 0 or 1.
 \item The driver MAY set \field{flags} to 1 to advise
-the device that interrupts are not needed.
+the device that notifications are not needed.
 \end{itemize}
 
 Otherwise, if the VIRTIO_F_EVENT_IDX feature bit is negotiated:
 \begin{itemize}
 \item The driver MUST set \field{flags} to 0.
-\item The driver MAY use \field{used_event} to advise the device that interrupts are unnecessary until the device writes entry with an index specified by \field{used_event} into the used ring (equivalently, until \field{idx} in the
+\item The driver MAY use \field{used_event} to advise the device that
+notifications are unnecessary until the device writes an entry with an index specified by \field{used_event} into the used ring (equivalently, until \field{idx} in the
 used ring will reach the value \field{used_event} + 1).
 \end{itemize}
 
-The driver MUST handle spurious interrupts from the device.
+The driver MUST handle spurious notifications from the device.
 
-\devicenormative{\subsubsection}{Virtqueue Interrupt Suppression}{Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Interrupt Suppression}
+\devicenormative{\subsubsection}{Used Buffer Notification Suppression}{Basic Facilities of a Virtio Device / Virtqueues / Used Buffer Notification Suppression}
 
 If the VIRTIO_F_EVENT_IDX feature bit is not negotiated:
 \begin{itemize}
 \item The device MUST ignore the \field{used_event} value.
 \item After the device writes a descriptor index into the used ring:
   \begin{itemize}
-  \item If \field{flags} is 1, the device SHOULD NOT send an interrupt.
-  \item If \field{flags} is 0, the device MUST send an interrupt.
+  \item If \field{flags} is 1, the device SHOULD NOT send a notification.
+  \item If \field{flags} is 0, the device MUST send a notification.
   \end{itemize}
 \end{itemize}
 
@@ -366,14 +370,16 @@ Otherwise, if the VIRTIO_F_EVENT_IDX feature bit is negotiated:
   \begin{itemize}
   \item If the \field{idx} field in the used ring (which determined
     where that descriptor index was placed) was equal to
-    \field{used_event}, the device MUST send an interrupt.
-  \item Otherwise the device SHOULD NOT send an interrupt.
+    \field{used_event}, the device MUST send a notification.
+  \item Otherwise the device SHOULD NOT send a notification.
   \end{itemize}
 \end{itemize}
 
 \begin{note}
 For example, if \field{used_event} is 0, then a device using
-  VIRTIO_F_EVENT_IDX would interrupt after the first buffer is
+
+  VIRTIO_F_EVENT_IDX would send a used buffer notification
+  to the driver after the first buffer is
   used (and again after the 65536th buffer, etc).
 \end{note}
 
@@ -460,14 +466,16 @@ that uninitialized memory has been overwritten when it has not.
 The driver MUST NOT make assumptions about data in device-writable buffers
 beyond the first \field{len} bytes, and SHOULD ignore this data.
 
-\subsection{Virtqueue Notification Suppression}\label{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Notification Suppression}
+\subsection{Available Buffer Notification Suppression}\label{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Notification Suppression}
 
-The device can suppress notifications in a manner analogous to the way
-drivers can suppress interrupts as detailed in section \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Interrupt Suppression}.
+The device can suppress available buffer notifications in a manner
+analogous to the way drivers can suppress used buffer notifications as
+detailed in section \ref{sec:Basic Facilities of a Virtio Device /
+Virtqueues / Used Buffer Notification Suppression}.
 The device manipulates \field{flags} or \field{avail_event} in the used ring the
 same way the driver manipulates \field{flags} or \field{used_event} in the available ring.
 
-\drivernormative{\subsubsection}{Virtqueue Notification Suppression}{Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Notification Suppression}
+\drivernormative{\subsubsection}{Available Buffer Notification Suppression}{Basic Facilities of a Virtio Device / Virtqueues / Available Buffer Notification Suppression}
 
 The driver MUST initialize \field{flags} in the used ring to 0 when
 allocating the used ring.
@@ -494,7 +502,7 @@ Otherwise, if the VIRTIO_F_EVENT_IDX feature bit is negotiated:
   \end{itemize}
 \end{itemize}
 
-\devicenormative{\subsubsection}{Virtqueue Notification Suppression}{Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Notification Suppression}
+\devicenormative{\subsubsection}{Available Buffer Notification Suppression}{Basic Facilities of a Virtio Device / Virtqueues / Available Buffer Notification Suppression}
 If the VIRTIO_F_EVENT_IDX feature bit is not negotiated:
 \begin{itemize}
 \item The device MUST set \field{flags} to 0 or 1.
@@ -562,8 +570,8 @@ The driver offers buffers to one of the device's virtqueues as follows:
 \item The driver performs a suitable memory barrier to ensure that it updates
   the \field{idx} field before checking for notification suppression.
 
-\item If notifications are not suppressed, the driver notifies the device
-    of the new available buffers.
+\item The driver sends an available buffer notification to the device if
+    such notifications are not suppressed.
 \end{enumerate}
 
 Note that the above code does not take precautions against the
@@ -659,26 +667,30 @@ The driver MUST perform a suitable memory barrier before reading \field{flags} o
 
 Once the device has used buffers referred to by a descriptor (read from or written to them, or
 parts of both, depending on the nature of the virtqueue and the
-device), it interrupts the driver as detailed in section \ref{sec:Basic Facilities of a Virtio Device / Virtqueues / Virtqueue Interrupt Suppression}.
+device), it sends a used buffer notification to the driver as detailed
+in section \ref{sec:Basic Facilities of a Virtio Device / Virtqueues /
+Used Buffer Notification Suppression}.
 
 \begin{note}
-For optimal performance, a driver MAY disable interrupts while processing
-the used ring, but beware the problem of missing interrupts between
-emptying the ring and reenabling interrupts.  This is usually handled by
-re-checking for more used buffers after interrups are re-enabled:
+
+For optimal performance, a driver MAY disable used buffer notifications
+while processing the used ring, but beware the problem of missing
+notifications between emptying the ring and reenabling notifications.  This
+is usually handled by re-checking for more used buffers after
+notifications are re-enabled:
 
 \begin{lstlisting}
-virtq_disable_interrupts(vq);
+virtq_disable_used_buffer_notifications(vq);
 
 for (;;) {
         if (vq->last_seen_used != le16_to_cpu(virtq->used.idx)) {
-                virtq_enable_interrupts(vq);
+                virtq_enable_used_buffer_notifications(vq);
                 mb();
 
                 if (vq->last_seen_used != le16_to_cpu(virtq->used.idx))
                         break;
 
-                virtq_disable_interrupts(vq);
+                virtq_disable_used_buffer_notifications(vq);
         }
 
         struct virtq_used_elem *e = virtq.used->ring[vq->last_seen_used%vsz];
-- 
1.7.1


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] Re: [PATCH v3 1/6] notifications: unify notifications wording in core

[Cornelia Huck]

On Mon, 25 Jun 2018 14:21:27 +0200
Halil Pasic <pasic@linux.ibm.com> wrote:

> Let us unify the wording when talking about notifications. This change
> establishes the terms available buffer notification for what was usually
> simply called notification or virtqueue notification in v1.0 and used
> buffer notification for what was usually called interrupt.
> 
> The term configuration change notification in kept where called so and
> consolidated where it's called configuration change interrupt or
> similar.
> 
> The changes done here are limited to the core part, and don't
> conceptually involve neither the transports nor the devices (references
> are updated though). Future changes should address these parts.
> 
> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
> ---
> v2 -> v3
> * Addressed all comments by Connie and Stefan (changed both directions
> with the my nonsensical "i.e.'s" that was pointed out by Stefan)
> * Added unrelated grammar fix s/writes entry/writes an entry/ (Stefan)
> ---
>  cl-os.tex       |    2 +-
>  conformance.tex |    8 +++---
>  content.tex     |   26 +++++++++++--------
>  packed-ring.tex |   60 ++++++++++++++++++++++++++--------------------
>  split-ring.tex  |   72 ++++++++++++++++++++++++++++++++-----------------------
>  5 files changed, 96 insertions(+), 72 deletions(-)
> 

> diff --git a/content.tex b/content.tex
> index be18234..9b1f3e1 100644
> --- a/content.tex
> +++ b/content.tex
(...)
> @@ -235,12 +236,13 @@ transmit and one for receive.}.
>  Driver makes requests available to device by adding
>  an available buffer to the queue - i.e. adding a buffer
>  describing the request to a virtqueue, and optionally triggering
> -a driver event - i.e. sending a notification to the device.
> +a driver event - i.e. sending an available buffer notification
> +to the device.
>  
>  Device executes the requests and - when complete - adds
>  a used buffer to the queue - i.e. lets the driver
>  know by marking the buffer as used. Device can then trigger
> -a device event - i.e. send an interrupt to the driver.
> +a device event - i.e. send a used buffer notification to the driver.
>  
>  Device reports the number of bytes it has written to memory for
>  each buffer it uses. This is referred to as ``used length''.

Unrelated: Device and driver are missing the definite article in some
places. Might be an idea for an additional patch :)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] Re: [virtio-dev] Re: [PATCH v3 1/6] notifications: unify notifications wording in core

[Halil Pasic]

On 06/25/2018 04:45 PM, Cornelia Huck wrote:
> On Mon, 25 Jun 2018 14:21:27 +0200
> Halil Pasic <pasic@linux.ibm.com> wrote:
> 
>> Let us unify the wording when talking about notifications. This change
>> establishes the terms available buffer notification for what was usually

[..]

>>   Device reports the number of bytes it has written to memory for
>>   each buffer it uses. This is referred to as ``used length''.
> 
> Unrelated: Device and driver are missing the definite article in some
> places. Might be an idea for an additional patch :)
> 

Yes, there are definitively other things that could be improved. For example
the capitalization in listing:

\begin{itemize}
\item Device status field
\item Feature bits
\item Notifications
\item Device Configuration space

Capital C in *C*onfiguration is most likely wrong.

\item One or more virtqueues
\end{itemize}

Regarding bullet points and capitalization, if the bullet
point is not a sentence but a fragment there seems to be multiple
viable styles. But I'm afraid we aren't consequent across the spec.

Another question is capitalization of 'virtio terms' like Available Ring.
On some occasions we write 'Available Ring' on others 'available ring'.

It would be nice to have a polished document. But for now I will try
to target fragments where the semantics suffers too. (I had another
series that I already presented as RFC but decided to not push in
parallel with this one).


> Reviewed-by: Cornelia Huck <cohuck@redhat.com>
>

Thanks!

Regards,
Halil


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] [PATCH v3 2/6] notifications: notifications as basic virtio facility

[Halil Pasic]

Let's introduce notifications as basic virtio facility early on. This
shall not only increase the cohesion between core and transport
description by having a well-defined  place where notifications are
introduced, but also give us the opportunity to explain some
discrepancies.

Namely notifications sent by the device to the driver were often called
interrupts prior to v1.1. Getting completely rid of that terminology is
however not viable in case of some names.

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
---
v2 -> v3:
* Consistent use of 'configuration change notification' (instead
of 'device configuration space notification' -- thanks Connie)
* s/semantic/semantics/ and comma (thanks Stefan)
---
 content.tex |   36 ++++++++++++++++++++++++++++++++++++
 1 files changed, 36 insertions(+), 0 deletions(-)

diff --git a/content.tex b/content.tex
index 9b1f3e1..15d9513 100644
--- a/content.tex
+++ b/content.tex
@@ -8,6 +8,7 @@ device consists of the following parts:
 \begin{itemize}
 \item Device status field
 \item Feature bits
+\item Notifications
 \item Device Configuration space
 \item One or more virtqueues
 \end{itemize}
@@ -150,6 +151,41 @@ requirements documented within these legacy interface sections.
 Specification text within these sections generally does not apply
 to non-transitional devices.
 
+\section{Notifications}\label{sec:Basic Facilities of a Virtio Device
+/ Notifications}
+
+The notion of sending a notification (driver to device or device
+to driver) plays an important role in this specification. The
+modus operandi of the notifications is transport specific.
+
+There are three types of notifications: 
+\begin{itemize}
+\item configuration change notification
+\item available buffer notification
+\item used buffer notification. 
+\end{itemize}
+
+Configuration change notifications and used buffer notifications are sent
+by the device, the recipient is the driver. A configuration change
+notification indicates that the device configuration space has changed; a
+used buffer notification indicates that a buffer may have been made used
+on the virtqueue designated by the notification.
+
+Available buffer notifications are sent by the driver, the recipient is
+the device. This type of notification indicates that a buffer may have
+been made available on the virtqueue designated by the notification.
+
+The semantics, the transport-specific implementations, and other
+important aspects of the different notifications are specified in detail
+in the following chapters.
+
+Most transports implement notifications sent by the device to the
+driver using interrupts. Therefore, in previous versions of this
+specification, these notifications were often called interrupts.
+Some names defined in this specification still retain this interrupt
+terminology. Occasionally, the term event is used to refer to
+a notification or a receipt of a notification.
+
 \section{Device Configuration Space}\label{sec:Basic Facilities of a Virtio Device / Device Configuration Space}
 
 Device configuration space is generally used for rarely-changing or
-- 
1.7.1


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] Re: [PATCH v3 2/6] notifications: notifications as basic virtio facility

[Cornelia Huck]

On Mon, 25 Jun 2018 14:21:28 +0200
Halil Pasic <pasic@linux.ibm.com> wrote:

> Let's introduce notifications as basic virtio facility early on. This
> shall not only increase the cohesion between core and transport
> description by having a well-defined  place where notifications are
> introduced, but also give us the opportunity to explain some
> discrepancies.
> 
> Namely notifications sent by the device to the driver were often called
> interrupts prior to v1.1. Getting completely rid of that terminology is
> however not viable in case of some names.
> 
> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
> ---
> v2 -> v3:
> * Consistent use of 'configuration change notification' (instead
> of 'device configuration space notification' -- thanks Connie)
> * s/semantic/semantics/ and comma (thanks Stefan)
> ---
>  content.tex |   36 ++++++++++++++++++++++++++++++++++++
>  1 files changed, 36 insertions(+), 0 deletions(-)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] [PATCH v3 3/6] ccw: map common notifications terminology to ccw

[Halil Pasic]

The various notifications are introduced and specified in the common
(i.e. transport agnostic) portion of this specification. How
notifications are realised for a given transport is something each
transport has to specify.

Let's make the relationship between the virtio-ccw terms and the common
terms more obvious.

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
---
 content.tex |   42 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 42 insertions(+), 0 deletions(-)

diff --git a/content.tex b/content.tex
index 15d9513..b4e8860 100644
--- a/content.tex
+++ b/content.tex
@@ -1943,6 +1943,18 @@ Bytes & Description & Contents \\
 \hline
 \end{tabular}
 
+A virtio-ccw proxy device facilitates:
+\begin{itemize} 
+\item Discovery and attachment of virtio devices (as described above).
+\item Initialization of virtqueues and transport-specific facilities (using
+      virtio-specific channel commands).
+\item Notifications (via hypercall and a combination of I/O interrupts
+      and indicator bits).
+\end{itemize} 
+
+\subsubsection{Channel Commands for Virtio}\label{sec:Virtio Transport Options / Virtio
+over channel I/O / Basic Concepts/ Channel Commands for Virtio}
+
 In addition to the basic channel commands, virtio-ccw defines a
 set of channel commands related to configuration and operation of
 virtio:
@@ -1963,6 +1975,36 @@ virtio:
 #define CCW_CMD_READ_STATUS 0x72
 \end{lstlisting}
 
+\subsubsection{Notifications}\label{sec:Virtio Transport Options / Virtio
+over channel I/O / Basic Concepts/ Notifications}
+
+Available buffer notifications are realized as a hypercall. No additional
+setup by the driver is needed. The operation of available buffer
+notifications is described in section \ref{sec:Virtio Transport Options /
+Virtio over channel I/O / Device Operation / Guest->Host Notification}.
+
+Used buffer notifications are realized either as so-called classic or
+adapter I/O interrupts depending on a transport level negotiation. The
+initialization is described in sections \ref{sec:Virtio Transport Options
+/ Virtio over channel I/O / Device Initialization / Setting Up Indicators
+/ Setting Up Classic Queue Indicators} and \ref{sec:Virtio Transport
+Options / Virtio over channel I/O / Device Initialization / Setting Up
+Indicators / Setting Up Two-Stage Queue Indicators} respectively.  The
+operation of each flavor is described in sections \ref{sec:Virtio
+Transport Options / Virtio over channel I/O / Device Operation /
+Host->Guest Notification / Notification via Classic I/O Interrupts} and
+\ref{sec:Virtio Transport Options / Virtio over channel I/O / Device
+Operation / Host->Guest Notification / Notification via Adapter I/O
+Interrupts} respectively. 
+
+Configuration change notifications are done using so-called classic I/O
+interrupts. The initialization is described in section \ref{sec:Virtio
+Transport Options / Virtio over channel I/O / Device Initialization /
+Setting Up Indicators / Setting Up Configuration Change Indicators} and
+the operation in section \ref{sec:Virtio Transport Options / Virtio over
+channel I/O / Device Operation / Host->Guest Notification / Notification
+via Classic I/O Interrupts}.
+
 \devicenormative{\subsubsection}{Basic Concepts}{Virtio Transport Options / Virtio over channel I/O / Basic Concepts}
 
 The virtio-ccw device acts like a normal channel device, as specified
-- 
1.7.1


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] [PATCH v3 4/6] pci: map common notifications terminology to PCI

[Halil Pasic]

The various notifications are introduced and specified in the common
(i.e. transport agnostic) portion of this specification. How
notifications are realised for a given transport is something each
transport has to specify.

Let's make the relationship between the PCI terms and the common
terms more obvious.

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
---
 conformance.tex |    2 +-
 content.tex     |   13 +++++++------
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/conformance.tex b/conformance.tex
index de33396..29969f1 100644
--- a/conformance.tex
+++ b/conformance.tex
@@ -180,7 +180,7 @@ A PCI device MUST conform to the following normative statements:
 \item \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / PCI configuration access capability}
 \item \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Device Initialization / Non-transitional Device With Legacy Driver}
 \item \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Device Initialization / MSI-X Vector Configuration}
-\item \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Virtqueue Interrupts From The Device}
+\item \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Used Buffer Notifications}
 \item \ref{devicenormative:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Notification of Device Configuration Changes}
 \end{itemize}
 
diff --git a/content.tex b/content.tex
index b4e8860..39a0536 100644
--- a/content.tex
+++ b/content.tex
@@ -941,7 +941,7 @@ causes the device to de-assert the interrupt.
 In this way, driver read of ISR status causes the device to de-assert
 an interrupt.
 
-See sections \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Virtqueue Interrupts From The Device} and \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Notification of Device Configuration Changes} for how this is used.
+See sections \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Used Buffer Notifications} and \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Notification of Device Configuration Changes} for how this is used.
 
 \devicenormative{\paragraph}{ISR status capability}{Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / ISR status capability}
 
@@ -1306,14 +1306,15 @@ enough to ensure that the separate parts of the virtqueue are on
 separate cache lines.
 }.  There was no mechanism to negotiate the queue size.
 
-\subsubsection{Notifying The Device}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Notifying The Device}
+\subsubsection{Available Buffer Notifications}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Available Buffer Notifications}
 
-The driver notifies the device by writing the 16-bit virtqueue index
+The driver sends an available buffer notification to the device by writing
+the 16-bit virtqueue index
 of this virtqueue to the Queue Notify address.  See \ref{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI Device Layout / Notification capability} for how to calculate this address.
 
-\subsubsection{Virtqueue Interrupts From The Device}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Virtqueue Interrupts From The Device}
+\subsubsection{Used Buffer Notifications}\label{sec:Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Used Buffer Notifications}
 
-If an interrupt is necessary for a virtqueue, the device would typically act as follows:
+If a used buffer notification is necessary for a virtqueue, the device would typically act as follows:
 
 \begin{itemize}
   \item If MSI-X capability is disabled:
@@ -1332,7 +1333,7 @@ If an interrupt is necessary for a virtqueue, the device would typically act as
     \end{enumerate}
 \end{itemize}
 
-\devicenormative{\paragraph}{Virtqueue Interrupts From The Device}{Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Virtqueue Interrupts From The Device}
+\devicenormative{\paragraph}{Used Buffer Notifications}{Virtio Transport Options / Virtio Over PCI Bus / PCI-specific Initialization And Device Operation / Used Buffer Notifications}
 
 If MSI-X capability is enabled and \field{queue_msix_vector} is
 NO_VECTOR for a virtqueue, the device MUST NOT deliver an interrupt
-- 
1.7.1


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] [PATCH v3 5/6] mmio: map common notifications terminology to MMIO

[Halil Pasic]

The various notifications are introduced and specified in the common
(i.e. transport agnostic) portion of this specification. How
notifications are realised for a given transport is something each
transport has to specify.

Let's make the relationship between the virtio over MIIO terms and the
common terms more obvious.

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
---
v2 -> v3:
* addresssed Connie's comments

---
 content.tex |   25 +++++++++++++------------
 1 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/content.tex b/content.tex
index 39a0536..5919cc1 100644
--- a/content.tex
+++ b/content.tex
@@ -1550,10 +1550,10 @@ All register values are organized as Little Endian.
     caused the device interrupt to be asserted.
     The following events are possible:
     \begin{description}
-      \item[Used Buffer Update] - bit 0 - the interrupt was asserted
+      \item[Used Buffer Notification] - bit 0 - the interrupt was asserted
         because the device has used a buffer
         in at least one of the active virtual queues.
-      \item [Configuration Change] - bit 1 - the interrupt was
+      \item [Configuration Change Notification] - bit 1 - the interrupt was
         asserted because the configuration of the device has changed.
     \end{description}
   }
@@ -1716,26 +1716,27 @@ The driver will typically initialize the virtual queue in the following way:
 \item Write 0x1 to \field{QueueReady}.
 \end{enumerate}
 
-\subsubsection{Notifying The Device}\label{sec:Virtio Transport Options / Virtio Over MMIO / MMIO-specific Initialization And Device Operation / Notifying The Device}
+\subsubsection{Available Buffer Notifications}\label{sec:Virtio Transport Options / Virtio Over MMIO / MMIO-specific Initialization And Device Operation / Available Buffer Notifications}
 
-The driver notifies the device about new buffers being available in
-a queue by writing the index of the updated queue to \field{QueueNotify}.
+The driver sends an available buffer notification to the device by
+writing the index of the queue to be notified to \field{QueueNotify}.
 
 \subsubsection{Notifications From The Device}\label{sec:Virtio Transport Options / Virtio Over MMIO / MMIO-specific Initialization And Device Operation / Notifications From The Device}
 
 The memory mapped virtio device is using a single, dedicated
 interrupt signal, which is asserted when at least one of the
 bits described in the description of \field{InterruptStatus}
-is set. This is how the device notifies the
-driver about a new used buffer being available in the queue
-or about a change in the device configuration.
+is set. This is how the device sends a used buffer notification
+or a configuration change notification to the device.
 
 \drivernormative{\paragraph}{Notifications From The Device}{Virtio Transport Options / Virtio Over MMIO / MMIO-specific Initialization And Device Operation / Notifications From The Device}
 After receiving an interrupt, the driver MUST read
-\field{InterruptStatus} to check what caused the interrupt
-(see the register description). After the interrupt is handled,
-the driver MUST acknowledge it by writing a bit mask
-corresponding to the handled events to the InterruptACK register.
+\field{InterruptStatus} to check what caused the interrupt (see the
+register description).  The used buffer notification bit being set
+SHOULD be interpreted as a used buffer notification for each active
+virtqueue.  After the interrupt is handled, the driver MUST acknowledge
+it by writing a bit mask corresponding to the handled events to the
+InterruptACK register.
 
 \subsection{Legacy interface}\label{sec:Virtio Transport Options / Virtio Over MMIO / Legacy interface}
 
-- 
1.7.1


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] Re: [PATCH v3 5/6] mmio: map common notifications terminology to MMIO

[Cornelia Huck]

On Mon, 25 Jun 2018 14:21:31 +0200
Halil Pasic <pasic@linux.ibm.com> wrote:

> The various notifications are introduced and specified in the common
> (i.e. transport agnostic) portion of this specification. How
> notifications are realised for a given transport is something each
> transport has to specify.
> 
> Let's make the relationship between the virtio over MIIO terms and the
> common terms more obvious.
> 
> Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
> ---
> v2 -> v3:
> * addresssed Connie's comments
> 
> ---
>  content.tex |   25 +++++++++++++------------
>  1 files changed, 13 insertions(+), 12 deletions(-)

Reviewed-by: Cornelia Huck <cohuck@redhat.com>

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] [PATCH v3 6/6] notifications: update notifications terminology for devices

[Halil Pasic]

The specifications of some virtio device types are still using the old
terminology for used buffer notifications and configuration change
notifications calling these interrupts.

Let us fix that.

Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 content.tex |   22 +++++++++++-----------
 1 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/content.tex b/content.tex
index 5919cc1..097af44 100644
--- a/content.tex
+++ b/content.tex
@@ -3043,9 +3043,9 @@ if VIRTIO_NET_F_MRG_RXBUF is not negotiated.}
 \label{sec:Device Types / Network Device / Device Operation / Processing of Packets}%old label for latexdiff
 
 When a packet is copied into a buffer in the receiveq, the
-optimal path is to disable further interrupts for the receiveq
-and process
-packets until no more are found, then re-enable them.
+optimal path is to disable further used buffer notifications for the
+receiveq and process packets until no more are found, then re-enable
+them.
 
 Processing incoming packets involves:
 
@@ -3885,7 +3885,7 @@ The device SHOULD clear the \field{write_zeroes_may_unmap} field of the
 virtio configuration space if and only if a write zeroes request cannot
 result in deallocating one or more sectors.  The device MAY change the
 content of the field during operation of the device; when this happens,
-the device SHOULD trigger a configuration change interrupt.
+the device SHOULD trigger a configuration change notification.
 
 A write is considered volatile when it is submitted; the contents of
 sectors covered by a volatile write are undefined in persistent device
@@ -4177,20 +4177,20 @@ an appropriate log or output method.
 \begin{enumerate}
 \item For output, a buffer containing the characters is placed in
   the port's transmitq\footnote{Because this is high importance and low bandwidth, the current
-Linux implementation polls for the buffer to be used, rather than
-waiting for an interrupt, simplifying the implementation
+Linux implementation polls for the buffer to become used, rather than
+waiting for a used buffer notification, simplifying the implementation
 significantly. However, for generic serial ports with the
 O_NONBLOCK flag set, the polling limitation is relaxed and the
 consumed buffers are freed upon the next write or poll call or
 when a port is closed or hot-unplugged.
 }.
 
-\item When a buffer is used in the receiveq (signalled by an
-  interrupt), the contents is the input to the port associated
+\item When a buffer is used in the receiveq (signalled by a
+  used buffer notification), the contents is the input to the port associated
   with the virtqueue for which the notification was received.
 
 \item If the driver negotiated the VIRTIO_CONSOLE_F_SIZE feature, a
-  configuration change interrupt indicates that the updated size can
+  configuration change notification indicates that the updated size can
   be read from the configuration fields.  This size applies to port 0 only.
 
 \item If the driver negotiated the VIRTIO_CONSOLE_F_MULTIPORT
@@ -4433,7 +4433,7 @@ The device initialization process is outlined below:
 \subsection{Device Operation}\label{sec:Device Types / Memory Balloon Device / Device Operation}
 
 The device is driven either by the receipt of a configuration
-change interrupt, or by changing guest memory needs, such as
+change notification, or by changing guest memory needs, such as
 performing memory compaction or responding to out of memory
 conditions.
 
@@ -4570,7 +4570,7 @@ and notifies the device. A request for memory statistics proceeds
 as follows:
 
 \begin{enumerate}
-\item The device uses the buffer and sends an interrupt.
+\item The device uses the buffer and sends a used buffer notification.
 
 \item The driver pops the used buffer and discards it.
 
-- 
1.7.1


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] Re: [PATCH v3 0/6] rework notifications terminology

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1566 bytes --]

On Mon, Jun 25, 2018 at 02:21:26PM +0200, Halil Pasic wrote:
> Abstract 
> --------
> The terminology around notifications is currently somewhat
> fragmented. Unify notifications terminology using available and used
> buffer notification consistently for the virtqueue notifications.
> Consistent use of the term configuration change notification is of
> concern.
> 
> Changelog:
> ---------
> v2 -> v3:
> * Addressed all comments from the previous round
> * Added r-b's
> 
> v1 -> v2:
> * Addressed Stefan's comments (mostly typos, grammar and inconsistencies).
>   Thanks Stefan!
> * Rebased onto the current master.
> 
> RFC -> v1:
> * Devices and the transports PCI and MMIO were omitted.
> Now the rework should be complete.
> * Addressed review comments and minor changes for the first
> three patches. 
> 
> Halil Pasic (6):
>   notifications: unify notifications wording in core
>   notifications: notifications as basic virtio facility
>   ccw: map common notifications terminology to ccw
>   pci: map common notifications terminology to PCI
>   mmio: map common notifications terminology to MMIO
>   notifications: update notifications terminology for devices
> 
>  cl-os.tex       |    2 +-
>  conformance.tex |   10 ++--
>  content.tex     |  164 +++++++++++++++++++++++++++++++++++++++++-------------
>  packed-ring.tex |   60 +++++++++++---------
>  split-ring.tex  |   72 ++++++++++++++----------
>  5 files changed, 206 insertions(+), 102 deletions(-)
> 

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

[virtio] Re: [virtio-dev] [PATCH v3 0/6] rework notifications terminology

[Michael S. Tsirkin]

On Mon, Jun 25, 2018 at 02:21:26PM +0200, Halil Pasic wrote:
> Abstract 
> --------
> The terminology around notifications is currently somewhat
> fragmented. Unify notifications terminology using available and used
> buffer notification consistently for the virtqueue notifications.
> Consistent use of the term configuration change notification is of
> concern.

OK I see there are acks already - do you want to start voting on this?



> Changelog:
> ---------
> v2 -> v3:
> * Addressed all comments from the previous round
> * Added r-b's
> 
> v1 -> v2:
> * Addressed Stefan's comments (mostly typos, grammar and inconsistencies).
>   Thanks Stefan!
> * Rebased onto the current master.
> 
> RFC -> v1:
> * Devices and the transports PCI and MMIO were omitted.
> Now the rework should be complete.
> * Addressed review comments and minor changes for the first
> three patches. 
> 
> Halil Pasic (6):
>   notifications: unify notifications wording in core
>   notifications: notifications as basic virtio facility
>   ccw: map common notifications terminology to ccw
>   pci: map common notifications terminology to PCI
>   mmio: map common notifications terminology to MMIO
>   notifications: update notifications terminology for devices
> 
>  cl-os.tex       |    2 +-
>  conformance.tex |   10 ++--
>  content.tex     |  164 +++++++++++++++++++++++++++++++++++++++++-------------
>  packed-ring.tex |   60 +++++++++++---------
>  split-ring.tex  |   72 ++++++++++++++----------
>  5 files changed, 206 insertions(+), 102 deletions(-)
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] Re: [virtio-dev] [PATCH v3 0/6] rework notifications terminology

[Cornelia Huck]

On Tue, 3 Jul 2018 03:01:56 +0300
"Michael S. Tsirkin" <mst@redhat.com> wrote:

> On Mon, Jun 25, 2018 at 02:21:26PM +0200, Halil Pasic wrote:
> > Abstract 
> > --------
> > The terminology around notifications is currently somewhat
> > fragmented. Unify notifications terminology using available and used
> > buffer notification consistently for the virtqueue notifications.
> > Consistent use of the term configuration change notification is of
> > concern.  
> 
> OK I see there are acks already - do you want to start voting on this?

Let's do that, the less dangling series we have, the better.

> 
> 
> 
> > Changelog:
> > ---------
> > v2 -> v3:
> > * Addressed all comments from the previous round
> > * Added r-b's
> > 
> > v1 -> v2:
> > * Addressed Stefan's comments (mostly typos, grammar and inconsistencies).
> >   Thanks Stefan!
> > * Rebased onto the current master.
> > 
> > RFC -> v1:
> > * Devices and the transports PCI and MMIO were omitted.
> > Now the rework should be complete.
> > * Addressed review comments and minor changes for the first
> > three patches. 
> > 
> > Halil Pasic (6):
> >   notifications: unify notifications wording in core
> >   notifications: notifications as basic virtio facility
> >   ccw: map common notifications terminology to ccw
> >   pci: map common notifications terminology to PCI
> >   mmio: map common notifications terminology to MMIO
> >   notifications: update notifications terminology for devices
> > 
> >  cl-os.tex       |    2 +-
> >  conformance.tex |   10 ++--
> >  content.tex     |  164 +++++++++++++++++++++++++++++++++++++++++-------------
> >  packed-ring.tex |   60 +++++++++++---------
> >  split-ring.tex  |   72 ++++++++++++++----------
> >  5 files changed, 206 insertions(+), 102 deletions(-)
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org  


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

Re: [virtio] Re: [virtio-dev] [PATCH v3 0/6] rework notifications terminology

[Halil Pasic]

On 07/03/2018 02:01 AM, Michael S. Tsirkin wrote:
> On Mon, Jun 25, 2018 at 02:21:26PM +0200, Halil Pasic wrote:
>> Abstract
>> --------
>> The terminology around notifications is currently somewhat
>> fragmented. Unify notifications terminology using available and used
>> buffer notification consistently for the virtqueue notifications.
>> Consistent use of the term configuration change notification is of
>> concern.
> 
> OK I see there are acks already - do you want to start voting on this?
> 
> 
> 

Yes, voting would make sense in my opinion.

Regards,
Halil


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] Re: [virtio-dev] Re: [virtio] Re: [virtio-dev] [PATCH v3 0/6] rework notifications terminology

[Halil Pasic]

On 07/03/2018 11:00 AM, Halil Pasic wrote:
> 
> 
> On 07/03/2018 02:01 AM, Michael S. Tsirkin wrote:
>> On Mon, Jun 25, 2018 at 02:21:26PM +0200, Halil Pasic wrote:
>>> Abstract
>>> --------
>>> The terminology around notifications is currently somewhat
>>> fragmented. Unify notifications terminology using available and used
>>> buffer notification consistently for the virtqueue notifications.
>>> Consistent use of the term configuration change notification is of
>>> concern.
>>
>> OK I see there are acks already - do you want to start voting on this?
>>
>>
>>
> 
> Yes, voting would make sense in my opinion.
> 


I've submitted a github issue. Please let me know if further actions are
required.

Regards,
Halil


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] Re: [virtio-dev] Re: [virtio] Re: [virtio-dev] [PATCH v3 0/6] rework notifications terminology

[Halil Pasic]

On 07/03/2018 02:07 PM, Halil Pasic wrote:
> 
> 
> On 07/03/2018 11:00 AM, Halil Pasic wrote:
>>
>>
>> On 07/03/2018 02:01 AM, Michael S. Tsirkin wrote:
>>> On Mon, Jun 25, 2018 at 02:21:26PM +0200, Halil Pasic wrote:
>>>> Abstract
>>>> --------
>>>> The terminology around notifications is currently somewhat
>>>> fragmented. Unify notifications terminology using available and used
>>>> buffer notification consistently for the virtqueue notifications.
>>>> Consistent use of the term configuration change notification is of
>>>> concern.
>>>
>>> OK I see there are acks already - do you want to start voting on this?
>>>
>>>
>>>
>>
>> Yes, voting would make sense in my opinion.
>>
> 
> 
> I've submitted a github issue. Please let me know if further actions are
> required.
> 

ping


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] Re: [virtio-dev] Re: [virtio] Re: [virtio-dev] [PATCH v3 0/6] rework notifications terminology

[Halil Pasic]

On 07/17/2018 06:47 PM, Halil Pasic wrote:
>>>>
>>>> OK I see there are acks already - do you want to start voting on this?
>>>>
>>>>
>>>>
>>>
>>> Yes, voting would make sense in my opinion.
>>>
>>
>>
>> I've submitted a github issue. Please let me know if further actions are
>> required.
>>
> 
> ping

ping


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[virtio] Re: [virtio-dev] Re: [virtio] Re: [virtio-dev] [PATCH v3 0/6] rework notifications terminology

[Michael S. Tsirkin]

On Fri, Jul 27, 2018 at 01:33:15PM +0200, Halil Pasic wrote:
> 
> 
> On 07/17/2018 06:47 PM, Halil Pasic wrote:
> > > > > 
> > > > > OK I see there are acks already - do you want to start voting on this?
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > Yes, voting would make sense in my opinion.
> > > > 
> > > 
> > > 
> > > I've submitted a github issue. Please let me know if further actions are
> > > required.
> > > 
> > 
> > ping
> 
> ping

Oh, sorry, I wasn't clear.
What you want to do is
1. post the patches including
Fixes: https://github.com/oasis-tcs/virtio-spec/issues/16
in the commit log part.
2. proposal must link to oasis archive, not mail-archive.

Anyway, I fixed the link and started voting now.

-- 
MST

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

Re: [virtio] Re: [virtio-dev] Re: [virtio] Re: [virtio-dev] [PATCH v3 0/6] rework notifications terminology

[Halil Pasic]

On 07/27/2018 01:45 PM, Michael S. Tsirkin wrote:
> On Fri, Jul 27, 2018 at 01:33:15PM +0200, Halil Pasic wrote:
>>
>>
>> On 07/17/2018 06:47 PM, Halil Pasic wrote:
>>>>>>
>>>>>> OK I see there are acks already - do you want to start voting on this?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> Yes, voting would make sense in my opinion.
>>>>>
>>>>
>>>>
>>>> I've submitted a github issue. Please let me know if further actions are
>>>> required.
>>>>
>>>
>>> ping
>>
>> ping
> 
> Oh, sorry, I wasn't clear.
> What you want to do is
> 1. post the patches including
> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/16
> in the commit log part.
> 2. proposal must link to oasis archive, not mail-archive.
> 
> Anyway, I fixed the link and started voting now.
> 

Should post a v4 (or a 'REPOST v3') with the r-b's received for
v3 and the 'Fixes' tags? I mean the ballot, would not link to the
final thread then. I'm a bit confused regarding now, but I
think I understood the process.

FYI I'm on and off starting tomorrow till 5th September. I
am very likely to make any ballots though, but longer response
times and lower availability are to be expected.

Thanks,
Halil


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

Re: [virtio] Re: [virtio-dev] Re: [virtio] Re: [virtio-dev] [PATCH v3 0/6] rework notifications terminology

[Michael S. Tsirkin]

On Wed, Aug 01, 2018 at 03:04:54PM +0200, Halil Pasic wrote:
> 
> 
> On 07/27/2018 01:45 PM, Michael S. Tsirkin wrote:
> > On Fri, Jul 27, 2018 at 01:33:15PM +0200, Halil Pasic wrote:
> > > 
> > > 
> > > On 07/17/2018 06:47 PM, Halil Pasic wrote:
> > > > > > > 
> > > > > > > OK I see there are acks already - do you want to start voting on this?
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > Yes, voting would make sense in my opinion.
> > > > > > 
> > > > > 
> > > > > 
> > > > > I've submitted a github issue. Please let me know if further actions are
> > > > > required.
> > > > > 
> > > > 
> > > > ping
> > > 
> > > ping
> > 
> > Oh, sorry, I wasn't clear.
> > What you want to do is
> > 1. post the patches including
> > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/16
> > in the commit log part.
> > 2. proposal must link to oasis archive, not mail-archive.
> > 
> > Anyway, I fixed the link and started voting now.
> > 
> 
> Should post a v4 (or a 'REPOST v3') with the r-b's received for
> v3 and the 'Fixes' tags? I mean the ballot, would not link to the
> final thread then. I'm a bit confused regarding now, but I
> think I understood the process.

I think you are right since ballot started no need for v4.

> FYI I'm on and off starting tomorrow till 5th September. I
> am very likely to make any ballots though, but longer response
> times and lower availability are to be expected.
> 
> Thanks,
> Halil

What are we going to do about crypto proposals? I think we do want to
finalize a draft for public review by september, and it seems
very unfortunate not to have that device in the draft at all.

-- 
MST

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

Re: [virtio] Re: [virtio-dev] Re: [virtio] Re: [virtio-dev] [PATCH v3 0/6] rework notifications terminology

[Halil Pasic]

On 08/02/2018 12:30 AM, Michael S. Tsirkin wrote:
> On Wed, Aug 01, 2018 at 03:04:54PM +0200, Halil Pasic wrote:
>>
>>
>> On 07/27/2018 01:45 PM, Michael S. Tsirkin wrote:
>>> On Fri, Jul 27, 2018 at 01:33:15PM +0200, Halil Pasic wrote:
>>>>
>>>>
>>>> On 07/17/2018 06:47 PM, Halil Pasic wrote:
>>>>>>>>
>>>>>>>> OK I see there are acks already - do you want to start voting on this?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Yes, voting would make sense in my opinion.
>>>>>>>
>>>>>>
>>>>>>
>>>>>> I've submitted a github issue. Please let me know if further actions are
>>>>>> required.
>>>>>>
>>>>>
>>>>> ping
>>>>
>>>> ping
>>>
>>> Oh, sorry, I wasn't clear.
>>> What you want to do is
>>> 1. post the patches including
>>> Fixes: https://github.com/oasis-tcs/virtio-spec/issues/16
>>> in the commit log part.
>>> 2. proposal must link to oasis archive, not mail-archive.
>>>
>>> Anyway, I fixed the link and started voting now.
>>>
>>
>> Should post a v4 (or a 'REPOST v3') with the r-b's received for
>> v3 and the 'Fixes' tags? I mean the ballot, would not link to the
>> final thread then. I'm a bit confused regarding now, but I
>> think I understood the process.
> 
> I think you are right since ballot started no need for v4.
> 

Thanks!

>> FYI I'm on and off starting tomorrow till 5th September. I
>> am very likely to make any ballots though, but longer response
>> times and lower availability are to be expected.
>>
>> Thanks,
>> Halil
> 
> What are we going to do about crypto proposals? I think we do want to
> finalize a draft for public review by september, and it seems
> very unfortunate not to have that device in the draft at all.
> 

As I wrote in the other thread I'm fine either way. But I don't
think I will be able to muster the time and go trough he spec
and the code by September. I have a couple of weeks of vacation
in August, but I intend to stay tuned.

Given the whole situation, I have the feeling merging the thing
even if it's a bit 'on risk' seems to be the most reasonable option.
I often tend to regard standards as 'holy cow that is cast in
stone'. That makes me over-cautious. If something needs to be
fixed, we can fix it when the need becomes apparent.

Best regards,
Halil


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php