Re: [PATCH v2 01/12] KVM: s390: leave AIs in IPM of GISA during vcpu_pre_run()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux