OASIS Open Mailing List Archives  ·  All Lists  ·  virtio  ·  2018-06

virtio — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

[PATCH v2 0/6] rework notifications terminology


On Mon, 11 Jun 2018 18:11:57 +0200 Halil Pasic <[email protected]> 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 <[email protected]> > --- > content.tex 26 ++++++++++++++ ------------ > 1 files changed, 14 insertions(+), 12 deletions(-) > > diff --git a/content.tex b/content.tex > index 98efdd2..213ecdf 100644 > --- a/content.tex > +++ b/content.tex (...) > @@ -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 by > +writing the index of the queue to field{QueueNotify} to be notified. That reads a bit awkward. "...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. > + Extra empty line? > +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} >

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]