On 11/20/2018 12:33 PM, 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 In fact, doing the inject when in SIE is likely better performance-wise. Right now we "inject" the floating interrupt and then we handle the requests. That can actually mean that it could take a while until the interrupt is actually noticed by the guest (when in SIE). If you now have a 2nd CPU enabled this interrupt could have been delivered to the guest much earlier but it is "stuck" in the local CPU. > > 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. FWIW, LPAR has the same relaxation regarding priorities of subclasses. > But maybe I'm just missing another bit of the code that makes this > safe. Can you elaborate a bit?
