Re: [PATCH 2/4] KVM: arm64: vgic: Move IRQ migrations out of vgic_prune_ap_list()

[Oliver Upton <oupton@kernel.org>]

Hi Fuad,

thanks for the review

On Wed, Sep 30, 2026 at 02:55:04PM +0100, Fuad Tabba wrote:
> Hi Oliver,
> 
> On Tue, 29 Sep 2026 22:29:23 +0100, Oliver Upton <oupton@kernel.org> wrote:
> [...]
> > diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
> [...]
> > +void __vgic_update_irq_affinity(struct kvm *kvm, struct vgic_irq *irq,
> > +                                struct kvm_vcpu *old, struct kvm_vcpu *new,
> > +                                u32 data)
> [...]
> > +        /* Fire! */
> > +        kvm_pause_vcpu(tmp);
> > +
> > +        scoped_guard(raw_spinlock_irqsave, &tmp->arch.vgic_cpu.ap_list_lock) {
> > +                scoped_guard(raw_spinlock, &irq->irq_lock) {
> > +                        /*
> > +                         * The IRQ could've been moved to another AP list after
> > +                         * dropping the irq_lock. Make sure it's where we expect
> > +                         * it to be, remove from the list and retain the implied
> > +                         * reference until we queue it on the new vCPU.
> > +                         */
> > +                        if (irq->vcpu == tmp) {
> > +                                list_del(&irq->ap_list);
> > +                                irq->vcpu = NULL;
> > +                                irq->target_vcpu = new;
> > +                                if (vgic_is_v2(kvm))
> > +                                        irq->targets = data;
> > +                                else
> > +                                        irq->mpidr = data;
> > +                                pruned = true;
> > +                        }
> 
> Could an active IRQ stay on its current vCPU until it's deactivated?
> With irq->vcpu cleared, the oracle returns target_vcpu for it, so with
> EOImode 0 the old vCPU's EOI finds no LR and the SPI stays active on
> the new vCPU. A scratch test moving the IROUTER of an active edge SPI
> loses it with this patch, but not on Marc's branch.

Ugh. Well spotted, of course. Too much time dealing with LPIs :)

Let me have a think about this. Ultimately the goal is to prevent the
guest from queueing up an unbounded amount of work in a context where
we can't schedule, but deactivation still requires some work to be done
locally on the vCPU.

We already have some infrastructure for async processing of the AP list
for EOImode=1, perhaps there's a chance for reusing that here with some
additional guardrails.

> Could this also make sure the IRQ isn't still in the old vCPU's LRs? A
> vCPU between the vgic flush and the IN_GUEST_MODE store is
> OUTSIDE_GUEST_MODE, so even kvm_arm_halt_guest() wouldn't wait for it.

So we set the request on the vCPU, which means we're guaranteed to sync
the LRs and recompute before entering the VM. This wouldn't affect
affinity changes but there's a chance of a stale LR overwriting the
current active/pending state. So yet another bug, ugh.

Thanks,
Oliver