On Tue, 20 Nov 2018 13:00:03 +0100 David Hildenbrand <david@xxxxxxxxxx> wrote: > On 20.11.18 12:33, Cornelia Huck wrote: > > On Mon, 19 Nov 2018 18:25:25 +0100 > > Michael Mueller <mimu@xxxxxxxxxxxxx> wrote: > > > >> Do not call __deliver_io() for adapter interruptions already > >> pending in the IPM. That is a double effort. They will > >> be processed as soon the vcpu control is given to SIE. > >> > >> Signed-off-by: Michael Mueller <mimu@xxxxxxxxxxxxx> > >> --- > >> arch/s390/kvm/interrupt.c | 54 > >> ++++++++++++++++++++++------------------------- 1 file changed, 25 > >> insertions(+), 29 deletions(-) > > > > I think this patch does what it says on the tin, but I'm a bit lost > > as to the why. (Might make more sense with the gib.) > > > > Currently, we are trying to process any I/O interrupts, even if we'd > > get them delivered via the gisa, when we're out of the SIE anyway. > > IIRC, while this looks a bit like a belt-and-suspenders approach, it > > also prevented performance problems when the vcpu did not go back > > into the SIE immediately (it even may exit to userspace). > > > > Also, if you're ignoring the I/O interrupts pending in the ipm, you > > may end up delivering interrupts with a lower priority (higher isc) > > first. I'm not sure that's what we want. > > > > But maybe I'm just missing another bit of the code that makes this > > safe. Can you elaborate a bit? > > > > For interrupt priorities to work at least somewhat predictable, we > should always try to inject all interrupts even if the HW would be > doing it for us. In the order of priority. > > But we don't have the same thing for external calls injected via SCA. > I remember that I once had a patch lying around a couple of years ago > to fix that ... it went missing :) > > IO interrupt almost have lowest priority, so letting the HW inject > them could be problematic when mixing IO interrupt priorities between > SW and HW injected ones (hat Conny described). > > There are other corner cases if a e.g. a RESTART interrupt is pending > for that CPU. We would deliver eventually the RESTART interrupt before > delivering the IO interrupt, which would be wrong. > I do share David's concern. Could somebody try to explain why this RESTART scenario David described is not actually a problem -- AFAIU it is a problem. Regards, Halil
