Re: [PATCH 5/5] KVM: s390: clear_io_irq() requests are not expected for adapter interrupts

[Cornelia Huck <cohuck@redhat.com>]

On Wed, 8 Nov 2017 13:14:01 +0100
Michael Mueller <mimu@linux.vnet.ibm.com> wrote:

> On 08.11.17 12:09, Cornelia Huck wrote:
> > On Wed, 8 Nov 2017 12:04:22 +0100
> > Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> >  
> >> On 11/08/2017 10:19 AM, Cornelia Huck wrote:  
> >>> On Wed,  8 Nov 2017 09:41:43 +0100
> >>> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> >>>      
> >>>> From: Michael Mueller <mimu@linux.vnet.ibm.com>
> >>>>
> >>>> There is a chance to delete not yet delivered I/O interrupts if an
> >>>> exploiter uses the subsystem identification word 0x0000 while
> >>>> processing a KVM_DEV_FLIC_CLEAR_IO_IRQ ioctl. -EINVAL will be returned
> >>>> now instead in that case.
> >>>>
> >>>> Classic interrupts will always have bit 0x10000 set in the schid while
> >>>> adapter interrupts have a zero schid. The clear_io_irq interface is
> >>>> only useful for classic interrupts (as adapter interrupts belong to
> >>>> many devices). Let's make this interface more strict and forbid a schid
> >>>> of 0.  
> >>> I'm wondering: Is there any possible use case to clear adapter
> >>> interrupts? This interface was introduced to handle the case where a
> >>> CRW was made pending for a subchannel (which implies any pending
> >>> interrupt needs to be cleared.)  
> >> The problem with clearing adapter interrupts is that is actually a summary
> >> interrupt for every potential device. So I somewhat consider an adapter interrupt
> >> pending when the summary indicator went from 0 to 1. So I dont think clearing
> >> a single one makes not much sense. (And this interface would be wrong for
> >> that I think)  
> > Yes, this interface would be problematic. I'm not sure what's supposed
> > to happen with crws vs. pending adapter interrupts, though.  
> They will be delivered based on ISC priority and the traditional first 
> when both have the same class.

I'm just wondering what is supposed to happen when all devices
associated with a summary indicator go away. The OS will hopefully
deregister the indicator if needed; the hypervisor might still set the
indicator and trigger an adapter interrupt before that happens (and
hopefully the OS can deal with that.)

Likely we don't have a problem, but I'm curious if there is anything
architected for the cases where real hardware exists (like qdio).

> >  
> >> The only use cases I can imagine for clearing adapter interrupts (e.g. reset)
> >> is already covered by KVM_DEV_FLIC_CLEAR_IRQS
> >>  
> >>> Alas, I cannot check the adapter interrupt question myself, as the
> >>> public doc is lacking :( But qdio as another adapter interrupt user
> >>> comes to mind (not that we support it in qemu, but still...)