[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio] [PATCH v12] VIRTIO_F_NOTIFICATION_DATA: extra data to devices
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]