Re: [PATCH v2 09/12] KVM: s390: make kvm_s390_get_io_int() aware of GISA

[Cornelia Huck <cohuck@redhat.com>]

On Fri, 26 Jan 2018 12:25:03 +0100
Christian Borntraeger <borntraeger@de.ibm.com> wrote:

> On 01/26/2018 12:21 PM, Cornelia Huck wrote:
> > On Fri, 26 Jan 2018 10:57:32 +0100
> > Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> >   
> >> On 01/26/2018 10:41 AM, Cornelia Huck wrote:  
> >>> On Thu, 25 Jan 2018 14:28:45 +0100
> >>> Christian Borntraeger <borntraeger@de.ibm.com> wrote:
> >>>     
> >>>> From: Michael Mueller <mimu@linux.vnet.ibm.com>
> >>>>
> >>>> The function returns a pending I/O interrupt with the highest
> >>>> priority defined by its ISC.
> >>>>
> >>>> Together with AIV activation, pending adapter interrupts are
> >>>> managed by the GISA IPM. Thus kvm_s390_get_io_int() needs to
> >>>> inspect the IPM as well when the interrupt with the highest
> >>>> priority has to be identified.
> >>>>
> >>>> In case classic and adapter interrupts with the same ISC are
> >>>> pending, the classic interrupt will be returned first.    
> >>>
> >>> Can this lead to starving? Consider a guest that never enables itself
> >>> for I/O interrupts, but collects pending interrupts via tpi. It will
> >>> always get the intis for an isc, but not the ai, wouldn't it?    
> >>
> >> Only if it handles the interrupts slower than new ones arrive, in that case
> >> you have a problem anyway. When looking at sane configuration, this priority
> >> makes sense as the classic interrupts are used for configuration type ccw,
> >> while adapter interrupts are for data. You want to get the control changes
> >> quickly. In a sane environment nobody would probably put devices with adapter
> >> interrupts on the same isc as different devices with only classic interrupts.  
> > 
> > But if you have a lot of devices, all using the same isc, you might
> > have a lot of classic interrupts (for example, due to firing a volley
> > of channel programs at all subchannels) and they could starve out the
> > device(s) that are waiting for adapter interrupts.
> > 
> > It's probably not a problem with today's guests (due to the control vs.
> > data semantics you pointed out above), especially as the only guest I
> > know that does not enable interrupts is the s390-ccw bios. But maybe
> > add a comment?  
> 
> Do you have some proposal for a comment? Then I can certainly add that.
> 

/*
 * Note that for a guest that does not enable I/O interrupts
 * but relies on TPI, a flood of classic interrupts may starve
 * out adapter interrupts on the same isc. Linux does not do
 * that, and it is possible to work around the issue by configuring
 * different iscs for classic and adapter interrupts in the guest,
 * but we may want to revisit this in the future.
 */

I think we don't really need to spend more time on that right now (and
probably complicate the code), so with the comment

Reviewed-by: Cornelia Huck <cohuck@redhat.com>