From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cornelia Huck Subject: Re: [PATCH v2 09/12] KVM: s390: make kvm_s390_get_io_int() aware of GISA Date: Fri, 26 Jan 2018 12:40:24 +0100 Message-ID: <20180126124024.671cbe5d.cohuck@redhat.com> References: <20180125132848.175942-1-borntraeger@de.ibm.com> <20180125132848.175942-10-borntraeger@de.ibm.com> <20180126104151.7cdfb156.cohuck@redhat.com> <20180126122146.65a4161f.cohuck@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: KVM , linux-s390 , Janosch Frank , David Hildenbrand , Martin Schwidefsky , Heiko Carstens , Michael Mueller To: Christian Borntraeger Return-path: Received: from mx1.redhat.com ([209.132.183.28]:34110 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751365AbeAZLkd (ORCPT ); Fri, 26 Jan 2018 06:40:33 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Fri, 26 Jan 2018 12:25:03 +0100 Christian Borntraeger wrote: > On 01/26/2018 12:21 PM, Cornelia Huck wrote: > > On Fri, 26 Jan 2018 10:57:32 +0100 > > Christian Borntraeger wrote: > > > >> On 01/26/2018 10:41 AM, Cornelia Huck wrote: > >>> On Thu, 25 Jan 2018 14:28:45 +0100 > >>> Christian Borntraeger wrote: > >>> > >>>> From: Michael Mueller > >>>> > >>>> 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