Re: [PATCH 1/4] content: Introduce driver/device auxiliary notifications

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Aug 10, 2022 at 11:54:35AM +0200, Cornelia Huck wrote:
> On Tue, Aug 09 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > On Wed, Mar 30, 2022 at 04:21:02PM +0100, Usama Arif wrote:
> >> Driver auxiliary notifications allow the device to send notifications
> >> other than configuration changes and used buffer notifications to the
> >> driver, these are optional and their meaning is device-specific.
> >> 
> >> Device auxiliary notifcations allow the driver to send notifcations
> >> other than available buffer notifications to the device for example
> >> through a device register, these are optional and their meaning is
> >> device-specific.
> >> 
> >> These device-specific notifications are needed later when adding support
> >> for virtio-vhost-user device.
> >> 
> >> Signed-off-by: Usama Arif <usama.arif@bytedance.com>
> >> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> >> Signed-off-by: Nikos Dragazis <ndragazis@arrikto.com>
> >
> > I see ccw is missing. Cornelia, any suggestions?
> 
> Hmm... I seem to be really behind on ccw things :(
> 
> We can probably use the following:
> 
> - for device->driver notification, use the next bit in the secondary
>   indicators (bit 0 is used for config change notification)
> - for driver->device notification, maybe use a new subcode for diagnose
>   0x500 (4 is probably the next free one?)
> 
> I have not looked at the requirements deeply, though.
> 
> This highlights another problem, however: When we introduce new features
> that require a transport-specific implementation, we often end up with a
> PCI implementation, but sometimes MMIO and more often ccw are left
> behind -- which is understandable, as PCI is what most people use, and
> ccw is something only a very few people are familiar with. This sadly
> means that we have a backlog of features supported in PCI, but not in
> ccw... requiring implementations for ccw would put an undue burden on
> contributors, as most of them are unlikely to write anything for a
> mainframe, ever. On the flip side, I do not have enough bandwith to deal
> with all of this.
> 
> Halil, any thoughts (on any of the above)?

Kind of depends. We Do we want to add a "universal config"
structure shared between transports?
Will help with some use-cases though not this one.


> >
> >> ---
> >>  content.tex | 35 ++++++++++++++++++++++-------------
> >>  1 file changed, 22 insertions(+), 13 deletions(-)
> >> 
> >> diff --git a/content.tex b/content.tex
> >> index c6f116c..85980ac 100644
> >> --- a/content.tex
> >> +++ b/content.tex
> >> @@ -160,29 +160,38 @@ \subsection{Legacy Interface: A Note on Feature
> >>  Specification text within these sections generally does not apply
> >>  to non-transitional devices.
> >>  
> >> -\section{Notifications}\label{sec:Basic Facilities of a Virtio Device
> >> -/ Notifications}
> >> +\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: 
> >> +There are five types of notifications:
> >>  \begin{itemize}
> >>  \item configuration change notification
> >>  \item available buffer notification
> >> -\item used buffer notification. 
> >> +\item used buffer notification
> >> +\item driver auxiliary notification
> >> +\item device auxiliary 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.
> >> +Configuration change notifications, used buffer notifications and
> >> +driver auxiliary 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; driver auxiliary notifications allow the
> >> +device to send notifications other than configuration changes and used
> >> +buffer notifications to the driver, these are optional and their meaning
> >> +is device-specific.
> >> +
> >> +Available buffer notifications and device auxiliary notifications
> >> +are sent by the driver, the recipient is the device. Available buffer
> >> +notifications indicate that a buffer may have been made available on the
> >> +virtqueue designated by the notification; device auxiliary
> >> +notifcations allow the driver to send notifcations other than available
> >> +buffer notifications to the device for example through a device register, these
> >> +are optional and their meaning is device-specific.
> >>  
> >>  The semantics, the transport-specific implementations, and other
> >>  important aspects of the different notifications are specified in detail
> >> -- 
> >> 2.25.1