Re: [PATCH v2] KVM: arm64: vgic: Do not remove in-flight LPIs from AP list on disable

[Marc Zyngier]

On Fri, 18 Sep 2026 20:15:56 +0100,
Oliver Upton <oupton@xxxxxxxxxx> wrote:
> 
> On Fri, Sep 18, 2026 at 12:58:17PM +0100, Fuad Tabba wrote:
> > Hi Yuchao,
> > 
> > On Fri, 18 Sept 2026 at 12:51, Yuchao Zhang <ndaugoing@xxxxxxxxx> wrote:
> > >
> > > Hi Fuad,
> > >
> > > Thanks a lot for pointing me to that thread! I was not aware of
> > > Hyunwoo's earlier report and the discussion with Oliver and Marc.
> > >
> > > I'll read through the thread and their rationale on the ap_list_lock
> > > approach. I'm happy to defer to Hyunwoo's effort to avoid duplicate
> > > work.
> > 
> > I'm not sure you should defer to their effort. It doesn't seem like
> > Hyunwoo has done any work on this for a while. I just wanted to point
> > you to the existing discussion.
> 
> Yuchao if you have cycles I would definitely appreciate it if you can
> pursue a fix. My view hasn't changed since before: let's make that
> traversal of the ap_list is done under the ap_list_lock, as this is not
> intended to be walked lock-free.
> 
> Taking a step back, the whole cross-vCPU LPI disabling always leaves me
> feeling ill... Really when RWP=0 becomes visible from another vCPU we
> need to guarantee that the LPIs have been actually retired, meaning we
> can't have one sitting in an LR. Even with the locking fix I think we
> miss this.
> 
> Given how unlikely it is for well-behaved software to disable LPIs
> remotely in the first place, I wonder if we should just halt the VM
> similar to how we handle accesses to the active state. That's a really
> big hammer but we've had a lot of bugs in this department and I'm
> somewhat biased towards an obviously correct solution.

Irrespective of the whole ap_list_lock issue, I think this is the only
valid option. Messing with the ap_list of another vcpu while it is
running can never result in something that actually works. There's a
hack doing that in my tree.

> We wouldn't need to do this for a vCPU disabling LPIs on its own
> redistributor since we've already exited the guest.

In general, we could stop the target vcpu only. But this is making
things more complex, and I quite like the idea of a large
hammer... ;-)

	M.

-- 
Jazz isn't dead. It just smells funny.