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

[Cornelia Huck <cohuck@redhat.com>]

On Wed, Aug 10 2022, "Michael S. Tsirkin" <mst@redhat.com> wrote:

> 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.

A "universal config" structure seems like a good idea; but, as you said,
that will not help in all cases.

>
>
>> >
>> >> ---
>> >>  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