All of lore.kernel.org
 help / color / mirror / Atom feed
From: Halil Pasic <pasic@linux.ibm.com>
To: virtio@lists.oasis-open.org, virtio-dev@lists.oasis-open.org
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Halil Pasic <pasic@linux.ibm.com>
Subject: [virtio] [PATCH 5/6] mmio: map common notifications terminology to MMIO
Date: Thu, 26 Apr 2018 13:00:01 +0200	[thread overview]
Message-ID: <1524740402-18934-6-git-send-email-pasic@linux.ibm.com> (raw)
In-Reply-To: <1524740402-18934-1-git-send-email-pasic@linux.ibm.com>

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>
---
 content.tex |   26 ++++++++++++++------------
 1 files changed, 14 insertions(+), 12 deletions(-)

diff --git a/content.tex b/content.tex
index ffd0c94..ed34495 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,28 @@ 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 a by
+writing the index of the queue to \field{QueueNotify} to be notified.
 
 \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 an used buffer notification
+or a configuration change notifaciton 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 


  parent reply	other threads:[~2018-04-26 11:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-26 10:59 [virtio] [PATCH 0/6] rework notifications terminology Halil Pasic
2018-04-26 10:59 ` [virtio] [PATCH 1/6] notifications: unify notifications wording in core Halil Pasic
2018-05-14 16:36   ` [virtio] Re: [virtio-dev] " Stefan Hajnoczi
2018-05-14 19:40     ` Halil Pasic
2018-05-15  9:09       ` Stefan Hajnoczi
2018-04-26 10:59 ` [virtio] [PATCH 2/6] notifications: notifications as basic virtio facility Halil Pasic
2018-05-14 17:24   ` [virtio] Re: [virtio-dev] " Stefan Hajnoczi
2018-05-15  9:09     ` Halil Pasic
2018-04-26 10:59 ` [virtio] [PATCH 3/6] ccw: map common notifications terminology to ccw Halil Pasic
2018-05-14 17:27   ` [virtio] Re: [virtio-dev] " Stefan Hajnoczi
2018-04-26 11:00 ` [virtio] [PATCH 4/6] pci: map common notifications terminology to PCI Halil Pasic
2018-05-15  8:51   ` Stefan Hajnoczi
2018-04-26 11:00 ` Halil Pasic [this message]
2018-05-15  8:58   ` [virtio] [PATCH 5/6] mmio: map common notifications terminology to MMIO Stefan Hajnoczi
2018-05-15  9:25     ` [virtio] Re: [virtio-dev] " Halil Pasic
2018-04-26 11:00 ` [virtio] [PATCH 6/6] notifications: update notifications terminology for devices Halil Pasic
2018-05-15  9:00   ` Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1524740402-18934-6-git-send-email-pasic@linux.ibm.com \
    --to=pasic@linux.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=mst@redhat.com \
    --cc=pawel.moll@arm.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtio@lists.oasis-open.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.