From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D963C606B5CA for ; Mon, 2 Nov 2026 14:16:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=CcbeYP31; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=WewyZlvL DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Unsubscribe-Post:List-Owner; bh=PAuzFOuclOSMC3fnm+jBEciQlj+SqOgZ/K1w8865E7Q=; b=CcbeYP31pgF1+3MuZEDOOzcwM8 PCHQadJwzDnCnTpToxInCdGVvIi91ntB+VOyoACo343OJCDL4l5PjJB5NouieuO1FBoQEF5Z16HUV Hz3bu5NAgOVF5jaQLGSmzy+eJqNw7wPyWTdonYt7gwdXVpiNtSHJdj5QfMd+ZhIiUGSrOtmX4Iq9Q KXH9YdzcAu4it1LFaS9iz7/WXKA/G3QzWNmSMxDmXey2DkCDZH2qoZDCcnOMvttjkuly6GHCayzwn vRQxdvylQiP0rH3d27FiIt3aBxHD8u29BhVykd3RFSDbSRXJ6WYzQiI7zHcgXxh0uAbJrJtUd4xe+ V10Ad8cA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xNsq4-0000000GlDT-3lug; Mon, 02 Nov 2026 14:16:44 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xNsq3-0000000GlDM-3twW for linux-arm-kernel@lists.infradead.org; Mon, 02 Nov 2026 14:16:43 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 658134386B; Mon, 2 Nov 2026 14:16:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 473361F00A18; Mon, 2 Nov 2026 14:16:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1793629003; bh=PAuzFOuclOSMC3fnm+jBEciQlj+SqOgZ/K1w8865E7Q=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=WewyZlvLd/tRB9W7Op0jcHwzO/nJrik6O/1bDl/hIi4CsBwgeAkNHKATizUZsplzK VlS8xH4qbw1szzCBVN6octtHmG4g3XelmIz07mRt2Z4Pdzrdc0V1By/Mh/QEgLEDUv dExjixtKNxEt1zlgnC3zuHvUF8trtUstZ9/mp08G7452k4jYtNlxEjmIc9nQ/K8UAv 3wskhVB+0LxmRntj4hvbRe7szA6Rbxuk6FajrLwerPlQjqpr9EFyjQJ+5wX5wUMA2K PcbawXfU/YwBlWvH52fIknOnFT4LieJILxnQNgGH1/EnmtpEVJfvYkUgyU79wEDuk4 44JtCx1V9i3YA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xNsq0-00000009sib-3jtI; Mon, 02 Nov 2026 14:16:40 +0000 Date: Mon, 02 Nov 2026 14:16:40 +0000 Message-ID: <86ecd32u9j.wl-maz@kernel.org> From: Marc Zyngier To: Ard Biesheuvel Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, Ard Biesheuvel , Oliver Upton , Fuad Tabba , Joey Gouly , Steffen Eiden , Suzuki K Poulose , Zenghui Yu 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) X-Archived-By: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: ardb+git@google.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, ardb@kernel.org, oupton@kernel.org, fuad.tabba@linux.dev, joey.gouly@arm.com, seiden@linux.ibm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" X-Spam-Status: No, score=-10.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 On Mon, 02 Nov 2026 09:47:49 +0000, Ard Biesheuvel wrote: > > From: Ard Biesheuvel > > 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.