[PATCH] KVM: arm64: Don't livelock when AT can't resolve a fault IPA

[Will Deacon]

On Mon, Nov 02, 2026 at 02:09:25PM +0000, Marc Zyngier wrote:
> On Mon, 02 Nov 2026 13:59:12 +0000,
> Will Deacon <will at kernel.org> wrote:
> > 
> > On Mon, Nov 02, 2026 at 10:47:49AM +0100, Ard Biesheuvel wrote:
> > > From: Ard Biesheuvel <ardb at kernel.org>
> 
> [...]
> 
> > > diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> > > index e0c55644224c..4ba61b71d511 100644
> > > --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> > > +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> > > @@ -843,8 +843,21 @@ static inline bool kvm_hyp_handle_cp15_32(struct kvm_vcpu *vcpu, u64 *exit_code)
> > >  static inline bool kvm_hyp_handle_memory_fault(struct kvm_vcpu *vcpu,
> > >  					       u64 *exit_code)
> > >  {
> > > -	if (!__populate_fault_info(vcpu))
> > > +	if (!__populate_fault_info(vcpu)) {
> > 
> > Presumably we need a barrier (DSB?) here, to ensure that the TLBI happens
> > after the AT instruction?
> >
> > > +		/*
> > > +		 * The AT couldn't resolve the IPA, typically because its
> > > +		 * stage-1 walk took a stage-2 fault, such as an Access flag
> > > +		 * fault on an aged page-table page. If the guest still has a
> > > +		 * cached translation for the VA, it won't take that fault
> > > +		 * itself, and would replay the same permission fault forever.
> > > +		 * Drop this VMID's TLB entries on this CPU, so that the replay
> > > +		 * walks the page tables and faults with a valid HPFAR_EL2.
> > > +		 */
> > > +		__tlbi(vmalls12e1);
> > 
> > Can we get away with an ALLE1 here, or do we really need to blow away the
> > whole lot?
> 
> ALLE1 blows EL1 translations for all VMIDs, while VMALLS12E1 is
> localised to this VMID. Feels like the latter is the least invasive
> option.
> 
> Alternatively, VMALLE1 or even VAE1 should be enough to get rid of the
> S1 TLB.

Ah, sorry, VMALLE1 is what I meant to ask about. I basically haven't
understood the need to invalidate the stage-2.

Will