On 28/11/2018 18:51, Michael Mueller wrote:
On 28.11.18 17:24, Pierre Morel wrote:
On 28/11/2018 11:19, Michael Mueller wrote:
The patch implements a handler for GIB alert interruptions
on the host. Its task is to alert storage backed guests that
interrupts are pending for them.
A GIB alert interrupt statistic counter is added as well:
$ cat /proc/interrupts
CPU0 CPU1
...
GAL: 0 0 [I/O] GIB Alert
...
Signed-off-by: Michael Mueller <mimu@xxxxxxxxxxxxx>
---
...
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index e00eae7ec0b8..283c51362ca8 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -3531,6 +3531,10 @@ static int vcpu_post_run(struct kvm_vcpu
*vcpu, int exit_reason)
vcpu->run->s.regs.gprs[15] = vcpu->arch.sie_block->gg15;
atomic_dec(&vcpu->kvm->arch.vcpus_in_sie);
+ if (vcpu->kvm->arch.gib_in_use &&
+ !in_alert_list(vcpu->kvm->arch.gisa) &&
+ !atomic_read(&vcpu->kvm->arch.vcpus_in_sie))
+ vcpu->kvm->arch.gisa->iam = vcpu->kvm->arch.iam;
Here, AFAIU, if the IAM is set, we must take care that not bit from IPM
for which IAM is set is also set otherwise we won't get an interruption.
My view is that we have a short time window between SIE exit and
the restoration of the IAM in the GISA, when an interruption might
be indicated by setting the respective ISC bit in the IPM. We will
not get an GAL interruption in the host for that. I think until
here we are on the same page, right?
In that situation the host needs to take action.
And it is taken, see the trace. These interruptions are delivered
outside of SIE because they are observed by:
kvm_s390_deliver_pending_interrupts()
deliverable_irqs(vcpu)
IPM != 0
__deliver_io()
If I don't make mistake, this code is only executed during vcpu_pre_run().
What I understand is that the next time the vcpu is scheduled, for
example due to another interrupt, the IPM interrupts are delivered
through this channel.
In the case the vcpu does not get scheduled they are not delivered.
00 01543426770:725504 4 - 01 00000000e280ea16 inject: I/O (AI/gisa) isc 3
00 01543426770:727023 4 - 02 00000000676fd4ca
00[0706c00180000000-00000000008e9428]: deliver: I/O (AI/gisa) isc 6
00 01543426770:727197 4 - 02 00000000676fd4ca
00[0706c00180000000-00000000008e9428]: deliver: I/O (AI/gisa) isc 6
00 01543426770:727353 4 - 02 00000000676fd4ca
00[0706c00180000000-00000000008e9428]: deliver: I/O (AI/gisa) isc 6
00 01543426770:727506 4 - 02 00000000676fd4ca
00[0706c00180000000-00000000008e9428]: deliver: I/O (AI/gisa) isc 6
00 01543426770:731878 4 - 02 00000000676fd4ca
00[0706c00180000000-00000000008e9428]: deliver: I/O (AI/gisa) isc 6
00 01543426770:731987 4 - 01 00000000e280ea16 inject: I/O (AI/gisa) isc 3
AFAIU you do not need to deliver IRQ which IPM is set in GISA during
vcpu_pre_run(), they will be delivered to the guest on SIE entry.
I tested this Code example in:
Message-Id: <1541009577-29656-8-git-send-email-pmorel@xxxxxxxxxxxxx>
Back to vcpu_post_run(), I am not sure that this is the better place to
reset the IAM.
Shouldn't we set the IAM only if the last active vcpu issues a halt?
Is there other SIE exit reasons to activate the alert list?
Regards,
Pierre
--
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany
