]> git.ipfire.org Git - thirdparty/linux.git/commit
KVM: arm64: vgic: Pick EOIcount deactivations from AP-list tail
authorMarc Zyngier <maz@kernel.org>
Sat, 7 Mar 2026 19:11:51 +0000 (19:11 +0000)
committerMarc Zyngier <maz@kernel.org>
Sat, 7 Mar 2026 21:45:58 +0000 (21:45 +0000)
commit6da5e537f5afe091658e846da1949d7e557d2ade
treedc818e53185ab240b867e71b15c9967ed2965563
parent3599c714c08c324f0fcfa392bfb857c92c575400
KVM: arm64: vgic: Pick EOIcount deactivations from AP-list tail

Valentine reports that their guests fail to boot correctly, losing
interrupts, and indicates that the wrong interrupt gets deactivated.

What happens here is that if the maintenance interrupt is slow enough
to kick us out of the guest, extra interrupts can be activated from
the LRs. We then exit and proceed to handle EOIcount deactivations,
picking active interrupts from the AP list. But we start from the
top of the list, potentially deactivating interrupts that were in
the LRs, while EOIcount only denotes deactivation of interrupts that
are not present in an LR.

Solve this by tracking the last interrupt that made it in the LRs,
and start the EOIcount deactivation walk *after* that interrupt.
Since this only makes sense while the vcpu is loaded, stash this
in the per-CPU host state.

Huge thanks to Valentine for doing all the detective work and
providing an initial patch.

Fixes: 3cfd59f81e0f3 ("KVM: arm64: GICv3: Handle LR overflow when EOImode==0")
Fixes: 281c6c06e2a7b ("KVM: arm64: GICv2: Handle LR overflow when EOImode==0")
Reported-by: Valentine Burley <valentine.burley@collabora.com>
Tested-by: Valentine Burley <valentine.burley@collabora.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20260307115955.369455-1-valentine.burley@collabora.com
Link: https://patch.msgid.link/20260307191151.3781182-1-maz@kernel.org
Cc: stable@vger.kernel.org
arch/arm64/include/asm/kvm_host.h
arch/arm64/kvm/vgic/vgic-v2.c
arch/arm64/kvm/vgic/vgic-v3.c
arch/arm64/kvm/vgic/vgic.c