diff options
| author | Marc Zyngier <maz@kernel.org> | 2026-03-07 19:11:51 +0000 |
|---|---|---|
| committer | Marc Zyngier <maz@kernel.org> | 2026-03-07 21:45:58 +0000 |
| commit | 6da5e537f5afe091658e846da1949d7e557d2ade (patch) | |
| tree | dc818e53185ab240b867e71b15c9967ed2965563 /Documentation/virtual/git@git.tavy.me:linux.git | |
| parent | 3599c714c08c324f0fcfa392bfb857c92c575400 (diff) | |
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
Diffstat (limited to 'Documentation/virtual/git@git.tavy.me:linux.git')
0 files changed, 0 insertions, 0 deletions
