Date: Mon, 02 Nov 2026 14:16:40 +0000
Message-ID: <86ecd32u9j.wl-maz@kernel.org>
From: Marc Zyngier <maz@kernel.org>
To: Ard Biesheuvel <ardb+git@google.com>
Cc: kvmarm@lists.linux.dev,
	linux-arm-kernel@lists.infradead.org,
	Ard Biesheuvel <ardb@kernel.org>,
	Oliver Upton <oupton@kernel.org>,
	Fuad Tabba <fuad.tabba@linux.dev>,
	Joey Gouly <joey.gouly@arm.com>,
	Steffen Eiden <seiden@linux.ibm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH] KVM: arm64: Don't livelock when AT can't resolve a fault IPA
In-Reply-To: <20261102094748.2638468-2-ardb+git@google.com>
References: <20261102094748.2638468-2-ardb+git@google.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue)
 FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/30.1
 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO)
Precedence: list
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII

On Mon, 02 Nov 2026 09:47:49 +0000,
Ard Biesheuvel <ardb+git@google.com> wrote:
> 
> From: Ard Biesheuvel <ardb@kernel.org>
> 
> When a stage-2 permission fault doesn't report its IPA in HPFAR_EL2,
> __get_fault_info() recovers it with an AT S1E1R/S1E1A on FAR_EL2. If that
> fails, kvm_hyp_handle_memory_fault() goes straight back to the guest, on
> the assumption that the replayed access will either succeed or take a
> fault that the slow path can handle.
> 
> That assumption doesn't hold when the AT fails because its stage-1 walk
> takes a stage-2 fault on one of the guest's page-table pages, while the
> guest still holds a cached translation for the faulting VA. The guest
> doesn't walk its page tables, so it never takes the S1PTW fault that
> would let the slow path fix things up. It takes the same permission fault
> again, the AT fails again, and the vCPU livelocks in the world switch.

That's because the TLBs tend to cache VA->PA, while ATS1R is after the
IPA.  So you get the permission fault from the TLB, and the access
fault from AT. Rinse, repeat.

Amazing find, really. This code has been in this exact shape for 13
years, and it took that long to notice the issue.

[...]

> 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)) {
> +		/*
> +		 * 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);

As I was saying in my response to Will, I reckon this could be made
more focused on the faulting VA. Something like:

	__tlbi(vae1, read_sysreg_el2(SYS_FAR));

If you respin, a Cc: stable would be appreciated.

Thanks,

	M.

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