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?
Function kvm_s390_deliver_pending_interrupts() is called in the
beginning of vcpu_pre_run() and we are about to enter the SIE anyway.
SIE will also grant the right ISC priority for adapter interruptions.
I basically want to avoid that a GISA that is part of the alert list
will get its IPM bits cleared outside the GIB alert interruption
context. process_gib_alert_list()
--
Mit freundlichen Grüßen / Kind regards
Michael Müller
IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294
