Re: [RFC PATCH 0/3] KVM: arm64: Preserve level IRQ re-pending

[Oliver Upton <oupton@kernel.org>]

On Thu, Oct 22, 2026 at 08:46:25AM +0200, Karl Mehltretter wrote:
> A guest can set a level interrupt pending again while handling it. The
> GIC records Active and Pending and delivers the interrupt after
> deactivation. KVM instead drops the second pending state for both the
> GICv2 and GICv3 backends.
> 
> The VGIC keeps software pending state outside the LR because commit
> 67b5b673ad4d stopped placing Pending and Active together for level
> interrupts. When the LR is folded, KVM cannot distinguish the pending
> state used to populate the LR from a later ISPENDR write. This series
> records the later write and preserves it across deactivation. The last
> patch adds a two-vCPU GICv3 selftest.
> 
> The awkward case, and the reason for the RFC, is a write from another
> vCPU while the interrupt remains in an LR. KVM cannot know whether the
> write preceded or followed the guest ack. This series preserves the
> write. A pre-ack write can therefore cause one extra delivery, while a
> post-ack write is no longer lost.
> 
> The exact alternative is to stop and synchronize the target vCPU
> before applying such a write, as the active-state accessors do. Is the
> conservative replay acceptable here, or should ISPENDR pay that
> synchronization cost?

Yes, just kick the target vCPU out and sync the LRs back into the VGIC
state. That's consistent with the approach we're taking everywhere else
where this sort of issue arises.

If we're lucky the vCPU is just poking at its own redistributor and the
synchronization is free.

> The issue was reproduced with Zephyr, NuttX and RT-Thread guests. On a
> Raspberry Pi 400 host with a GIC-400, each GICv2 guest handled the SPI
> once before the fix and twice afterwards.

Have you configured these guests in such a way to reproduce the issue?
What exactly are they doing that is susceptible to this issue?

Thanks,
Oliver