Re: [PATCH v2 0/7] KVM: arm64: vgic-v3: Make LPI disabling robust (and more)

[Oliver Upton <oupton@kernel.org>]

Hi Fuad,

On Thu, Oct 08, 2026 at 07:15:46PM +0100, Fuad Tabba wrote:
> Hi Marc,
> 
> On Tue, 29 Sep 2026 10:35:41 +0100, Marc Zyngier <maz@kernel.org> wrote:
> [...]
> > Address the two issues in one go, by actively taking a refcount on all
> > IRQs referenced by last_lr_irq, and making sure that disabling LPIs
> > force all vcpus to be paused, making it safe.
> 
> I'm triaging Sashiko's pre-existing bug database, and I ran into
> something that I think this series doesn't cover.
> 
> vgic_its_inject_cached_translation() doesn't check vgic_lpis_enabled()
> (the slow path, vgic_its_resolve_lpi(), does), and pausing the vCPUs
> doesn't stop an MSI coming in through irqfd or KVM_SIGNAL_MSI. So an
> MSI that hits the translation cache between vgic_flush_pending_lpis()
> and vgic_its_invalidate_all_caches() can still end up on the ap_list
> of a vCPU whose LPIs are being disabled, after the flush.
> 
> Could the cached path check vgic_lpis_enabled() on the target vCPU, or
> am I missing something?

Hmm, since there's no parent lock between disabling LPIs and translation
cache fills I believe there's still a chance for this to race. We could
have vgic_target_oracle() return NULL if LPIs are disabled at the
redistributor, then the rest of the AP list machinery will "just work"
for injections that slip between the cracks.

If only Arm went a bit further than "strongly recommends" on migrating
LPIs _before_ flipping the bit...

Thanks,
Oliver