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