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

[Marc Zyngier <maz@kernel.org>]

On Mon, 02 Nov 2026 13:59:12 +0000,
Will Deacon <will@kernel.org> wrote:
> 
> On Mon, Nov 02, 2026 at 10:47:49AM +0100, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@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.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.