On 20/11/2018 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?
I do not think we should worry.
In the architecture all interrupts are asynchronous to any activity of
the CPU.
The priority of the interrupt is controlled intern by each sub-channel
and adapter and then the by each CPU among sub-channel and adapter requests.
While the first system is completely hardware dependent the second is
collisioning with software IRQ we may dispatch out of KVM/QEMU.
The assignment of these priority is model dependent and must guarantee
that no interrupt is delayed so much that it could cause recovery
actions to be initiated.
In our case, we can take for sure that the priority seen by the vCPU,
that is dispatched by the software by touching the SIE page or by the
GISA mechanism, are compatible with the architecture.
If we agree on this the only problem may arise from the first level of
interruption also inside the subchannel priority mechanism and from the
delay induced by GISA when delivering these interrupts to the vCPU.
This delay occurs on an asynchronous interrupt, so yes, there will be a
delay.
Is it larger or smaller than the delay introduced by the software?
Why should we worry if it is, the interrupt is asynchronous, should we
worry, for example, if the AP card take longer to send the interrupt?
I don't think so.
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
