Re: [virtio] [PATCH v12] VIRTIO_F_NOTIFICATION_DATA: extra data to devices

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

On Thu, Mar 29, 2018 at 03:04:55PM +0200, Cornelia Huck wrote:
> On Thu, 29 Mar 2018 15:52:34 +0300
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> 
> > On Thu, Mar 29, 2018 at 11:05:55AM +0200, Cornelia Huck wrote:
> > > On Wed, 28 Mar 2018 20:21:47 +0300
> > > "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > >   
> > > > On Wed, Mar 28, 2018 at 06:56:13PM +0200, Halil Pasic wrote:  
> 
> > > > > The notifications *sent by the device to the driver (virtqueue or
> > > > > configuration change)* are often referred to as *interrupts* but occasionally
> > > > > also as notifications (e.g. 'host->guest notification').  
> > > 
> > > I think 'notifications' is a better term for these. I'm thinking of a
> > > driver polling for outstanding notifications from the device, no
> > > interrupts involved.  
> > 
> > In this context when polling there are no notifications - rememeber we are
> > talking about notification suppression.
> 
> OK, that's my s390 background again. We can easily make notification
> status available (setting indicators, making a subchannel status
> pending), but not deliver an interrupt because the guest has not
> enabled interrupts and polls instead. (In fact, such an operation mode
> is not uncommon for the traditional s390 OSs.)
> 
> But we can also just keep this as-is, it's probably not confusing for
> most people anyway.

Oh I see. In theory MSI also has on-device bits to signal events. They
are still called "interrupt pending" there.

It's up to you guys then.

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