summaryrefslogtreecommitdiff
path: root/Documentation/virtual/git@git.tavy.me:linux.git
diff options
context:
space:
mode:
authorMarc Zyngier <maz@kernel.org>2026-03-07 19:11:51 +0000
committerMarc Zyngier <maz@kernel.org>2026-03-07 21:45:58 +0000
commit6da5e537f5afe091658e846da1949d7e557d2ade (patch)
treedc818e53185ab240b867e71b15c9967ed2965563 /Documentation/virtual/git@git.tavy.me:linux.git
parent3599c714c08c324f0fcfa392bfb857c92c575400 (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