From nobody Wed Jun 17 04:03:52 2026 Received: from mail-ed1-f73.google.com (mail-ed1-f73.google.com [209.85.208.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7F5D63ECBDD for ; Tue, 28 Apr 2026 10:30:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372214; cv=none; b=J3I13WK941vi98zwC6aiYtFKbylQqAY8+533q54vuylpkKySsnJ00kQ07W+hG1SVQCph3Jn3j6iouNupY13wypZ8JSYpvs1n5KrGafwHfcJk/6kt+uOc1xuOL5bPIw4A4Jpr8WKHZKEvKCPPvQkpXI7ol8UqFpMfOQGdE/VFrMU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372214; c=relaxed/simple; bh=9Wt0iy5ayw0cQwuJpZ/wnzJmfEyzqf8hdthusy325Pw=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=B1s1SE3jFPQmNbe++ccjJ6CTFspCAloIlOIEV8XlHuBdVWJ9S1w3DSjxwJys5uRvqie8oxqY3cl1nyVy3nZMPhSqpgn0bwwLQJULE7tW8mh/eIv53eqXDxpmtLa0IQ8waGBWxtOTZZz6Vy3conTII1uDfboQX13pSKUJ+PkhwZg= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=u+efvmnI; arc=none smtp.client-ip=209.85.208.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="u+efvmnI" Received: by mail-ed1-f73.google.com with SMTP id 4fb4d7f45d1cf-671bcc1e533so10870208a12.0 for ; Tue, 28 Apr 2026 03:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777372211; x=1777977011; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=J7c867vhN0NJ0ysluuN7kPjni8MsLU+yiUrh20mCAzU=; b=u+efvmnIaOsAO0tdp6+xA05ecNTa5yClmUrtISo4sBE7lb1SaCt9spwcAZzdwtUrx6 a0KIDTAS3xofORai0TYETJN7f3ooWHbrmnpHhCuR2or5ykQF7WrMSzgXv3sXq1Gv5mRl 4glRb+oCLir4POt27218sdrQymFA/5Icj62N2tCWUTwuuMt/2c8Nh5Ozo3cs/E8iuK4w 1Ca+dIzj1o0WmBB/7GidtNbjM9Mp22r1AOyrbn6Oilj5kS12uenFBWHKl5vWjozpd/ET Gu1VvT0eAB5mZssDJ9NBr8WoExZ/LSoEA9lkKPEukCpGT+PsvgF+WyhW4aodB2JzDkw4 6CeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777372211; x=1777977011; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=J7c867vhN0NJ0ysluuN7kPjni8MsLU+yiUrh20mCAzU=; b=HtaTN6FcvFtY1Vk/YJWUUtrfnS66PssCGkUcb+Jea8ECusUZsVw6aC8FDN8f6d1c76 /UCEbPz8RJ2Ny1zTHwB7EPs6y4AADBy+UeWhJCHqrBU7tHhwmxWHDQkRdgledl7eRFkr r8UIdVIlFNxHKPG8bhgZ58bTcffrxKyKEL9d9QthHgDBkbwUe6w+K1tPxzsYJSye4bkE Xga18gHjeK03bdNCGxwx9bR4bQF/aeZ1DiJHrCHlw0twkulkpBOjYsUakwBVBUjN0pvH /3wRtuPa5++4ohrlv6HnThdtt6Fi3R1TfI8HXI6kbcPkwq4cA+SqAOlRqhq6s1g/4zEt FRzQ== X-Forwarded-Encrypted: i=1; AFNElJ8umacBQGUTpv33qIB6hQ397wvYmWZohlDHdYRJF8dyXvcikYyYAAW17MHJPJy1nKK/9b+/veGrmp78GQk=@vger.kernel.org X-Gm-Message-State: AOJu0Yy0pymmzRUtTuI1SvDfuBDjSDnYdeJgvo7WhqJjI2Gss9xFFoCO f47eKObU+RwchnD7RT3Z8REOPrqLbeX36hSDds2FT07Lp471X7siYSN34JZcV10VXllsKdT6yQ7 G/w== X-Received: from edru26.prod.google.com ([2002:aa7:d55a:0:b0:674:1e56:7dde]) (user=tabba job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6402:158d:b0:678:a553:bcf3 with SMTP id 4fb4d7f45d1cf-679bb0a125bmr1160027a12.21.1777372210503; Tue, 28 Apr 2026 03:30:10 -0700 (PDT) Date: Tue, 28 Apr 2026 11:30:01 +0100 In-Reply-To: <20260428103008.696141-1-tabba@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260428103008.696141-1-tabba@google.com> X-Mailer: git-send-email 2.54.0.545.g6539524ca2-goog Message-ID: <20260428103008.696141-2-tabba@google.com> Subject: [PATCH 1/8] KVM: arm64: Make EL2 exception entry and exit context-synchronization events From: Fuad Tabba To: maz@kernel.org, oliver.upton@linux.dev Cc: james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, qperret@google.com, vdonnefort@google.com, tabba@google.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" SCTLR_EL2.EIS and SCTLR_EL2.EOS control whether exception entry and exit at EL2 are Context Synchronisation Events (CSEs). Per ARM DDI 0487 M.b, EIS is governed by D1.4.2 rule RBBSRF (p. D1-7205) and EOS by D1.4.4.1 rule RBWCFK (p. D1-7209). D24.2.175 (p. D24-9754): - !FEAT_ExS: the bit is RES1, so the entry/exit is unconditionally a CSE. - FEAT_ExS: the reset value is architecturally UNKNOWN; software must set the bit to make the entry/exit a CSE. INIT_SCTLR_EL2_MMU_ON in arch/arm64/include/asm/sysreg.h sets neither bit. KVM/arm64 hot paths rely on ERET from EL2 being a CSE, and on synchronous EL1->EL2 entry being a CSE, to elide explicit ISBs after MSRs to context-switching system registers (HCR_EL2, HFGxTR_EL2, HCRX_EL2, ZCR_EL2, CPACR_EL1, CPTR_EL2, SCTLR_EL1, ptrauth keys, etc.); examples include the activate-traps path, ptrauth_switch_to_guest, and the FPSIMD trap re-enable in kvm_hyp_handle_fpsimd. On FEAT_ExS hardware those reliances are not architecturally backed unless EOS=3D1 (and, for entry, EIS=3D1), and whether they hold today depends on firmware initialisation outside the kernel's control. Make the guarantee explicit: include SCTLR_ELx_EIS | SCTLR_ELx_EOS in INIT_SCTLR_EL2_MMU_ON so that EL2 exception entry and exit are unconditionally CSEs regardless of whether FEAT_ExS is implemented. This matches the pairing in arch/arm64/kvm/config.c which treats EIS and EOS together as RES1 under !FEAT_ExS. INIT_SCTLR_EL2_MMU_OFF is left unchanged: that path is used during very early EL2 init and the EL2 MMU-off transition, neither of which relies on these bits in the same way. Fixes: fe2c8d19189e ("KVM: arm64: Turn SCTLR_ELx_FLAGS into INIT_SCTLR_EL2_= MMU_ON") Signed-off-by: Fuad Tabba Reviewed-by: Yuan Yao --- arch/arm64/include/asm/sysreg.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysre= g.h index 736561480f36..7aa08d59d494 100644 --- a/arch/arm64/include/asm/sysreg.h +++ b/arch/arm64/include/asm/sysreg.h @@ -844,7 +844,7 @@ #define INIT_SCTLR_EL2_MMU_ON \ (SCTLR_ELx_M | SCTLR_ELx_C | SCTLR_ELx_SA | SCTLR_ELx_I | \ SCTLR_ELx_IESB | SCTLR_ELx_WXN | ENDIAN_SET_EL2 | \ - SCTLR_ELx_ITFSB | SCTLR_EL2_RES1) + SCTLR_ELx_ITFSB | SCTLR_ELx_EIS | SCTLR_ELx_EOS | SCTLR_EL2_RES1) =20 #define INIT_SCTLR_EL2_MMU_OFF \ (SCTLR_EL2_RES1 | ENDIAN_SET_EL2) --=20 2.54.0.545.g6539524ca2-goog From nobody Wed Jun 17 04:03:52 2026 Received: from mail-ej1-f74.google.com (mail-ej1-f74.google.com [209.85.218.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3C4E311959 for ; Tue, 28 Apr 2026 10:30:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372215; cv=none; b=Kty8HVcmYrQddbn3rLXMNcumMKy6XdzP5pDWlkpZ025JclzUeR1gOeJV7z8yPfyzHKQTPNz2gvC15dLm3jM8GIImxludn+n6SSEdtG8YYPxuJ3PIaDYz7i4/TnS89ySsB3mObshh7BvcZpiH7x4px3NpFG7emcXXsg7CZWpD46E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372215; c=relaxed/simple; bh=dwxEJdIz8vYk/ufo4vzAXxS0t3GaEBIy02K4bnRRtU8=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=d1FXsSaLGDoK1HceTYVCSNQ4lmyaJUe97RO0GYnWbnO9Drh9NyrZiwAq+PfOz2JRc4yRbZXhn9RAm9XhnJO6abzZ2txQ0jdcW7HsZRmzyudW3qJVP5W7bYDcaIOEuTiTq13c4HbNGUtKfzzlP7Ol+H9h8mocLwSLDznioo9UQH4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=e6IRx0+U; arc=none smtp.client-ip=209.85.218.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="e6IRx0+U" Received: by mail-ej1-f74.google.com with SMTP id a640c23a62f3a-ba84b4c7130so774052266b.0 for ; Tue, 28 Apr 2026 03:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777372212; x=1777977012; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=xE/iPxwYzw+NNX7wEA81VsFDw/XB5o3T+Ctb9g0a1xk=; b=e6IRx0+U4D1sM2MtUx43QYhfzNuFJFSaIPGqxpEiLx7giEXt7+O8vaShHN4rZcxsau ReFayr3cJ2UuWvWKTJtT0dqvvXzIPBLEJ4GOl4noxXXosWZhdlXBrqLNsrJSM5ZrMIfq 2kooGIWtX9TS2+FBF/g2UMHD9hleNfQyyYME8jAaQ12h3KlxF2HPpOd3uSFT4ETk7OUR sgHNRJWvj5xoNDlJR/IRf6fK9oP2+FuMtV+6cbV5zwyIA+hxJ9FujqyGTYHreTF4gBUW Kuof96OccqkJMzviokszYI2LO05hu0Tqjz2J+AvqQyTxovBKD7TekCVFnR/fV4OVN5VI Beaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777372212; x=1777977012; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xE/iPxwYzw+NNX7wEA81VsFDw/XB5o3T+Ctb9g0a1xk=; b=GjPyltKVrFHKZ4lS/6DETwHJ88zkmZtk0ty0evtDXimV1MEm+9wDt3kpc8BHS0cktJ jNLC3/e7VD5aDoZU4RI5kjwMYI6nZimtUBID13VWevKqFjGzNo1/6PiOPQ5HHZuPmHVB uWWlplBBpz98q4bfhd/xuGYOy7Yyv3v2yMla3Hg/yHq2pNmd8yziqbI7/ieISZR7bqU+ T5dnQK4CJ1OR9jjFTbudNyqv+KpC/kWCeRU1wzHNqPka9JA1SFdo9PE8wewUNf75Mb4E XAMfMWjND9FWsyYnX07PTVLSSKAwYD2JCpp2d4iLJ/cKFa47N5V2prgyFBczsOUgTQ58 7A6A== X-Forwarded-Encrypted: i=1; AFNElJ82t+EN5uCSdiyIkcln9rcXYfp08/FozvfT1yZsAO7hLwdvkHRi/mdFBbdfSuJnmIw0AyD/y2wOPi6vwTw=@vger.kernel.org X-Gm-Message-State: AOJu0Yxtip1x7n3neSuejxgSCgPPO4wxvrRLxpH1/lxzhdXfnOJLIOKH LK8ydFcwr0Btq3W+KBpr4Q87Spr7QQyuz4oANkYHb/r8audOGgn0MwMekbYxsjke4Z6yNlwECRQ nCg== X-Received: from ejchp42.prod.google.com ([2002:a17:907:3e2a:b0:b9e:2534:71c9]) (user=tabba job=prod-delivery.src-stubby-dispatcher) by 2002:a17:906:5194:20b0:bae:656b:2953 with SMTP id a640c23a62f3a-bb8022c28ebmr102260866b.11.1777372211619; Tue, 28 Apr 2026 03:30:11 -0700 (PDT) Date: Tue, 28 Apr 2026 11:30:02 +0100 In-Reply-To: <20260428103008.696141-1-tabba@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260428103008.696141-1-tabba@google.com> X-Mailer: git-send-email 2.54.0.545.g6539524ca2-goog Message-ID: <20260428103008.696141-3-tabba@google.com> Subject: [PATCH 2/8] KVM: arm64: Synchronise HCR_EL2 writes on the guest exit path From: Fuad Tabba To: maz@kernel.org, oliver.upton@linux.dev Cc: james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, qperret@google.com, vdonnefort@google.com, tabba@google.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" MSR HCR_EL2 is not self-synchronising. Per ARM DDI 0487 M.b K1.2.4 (p.K1-16823) and B2.6.1 (p.B2-297), a Context Synchronisation Event is required between an HCR_EL2 write and any subsequent direct register access at the same EL that depends on the new value being in effect. On the entry path, the HCR_EL2 write in __activate_traps is followed by further EL2 sysreg work (MDCR_EL2, CPTR_EL2, VBAR_EL2, and on the speculative-AT errata path SCTLR_EL1/TCR_EL1) before ERET into the guest. None of those intervening accesses depend on the new HCR_EL2 value, and ERET is a CSE per ARM DDI 0487 M.b D1.4.4.1 rule RBWCFK (p. D1-7209) conditional on SCTLR_EL2.EOS=3D1, which is set unconditionally by INIT_SCTLR_EL2_MMU_ON (see the prerequisite patch in this series). The requirement is therefore satisfied implicitly on the activate path. The deactivate path is different: after write_sysreg_hcr() in __deactivate_traps() further EL2 sysreg work runs before any natural CSE - on nVHE, __deactivate_cptr_traps and the VBAR_EL2 write; on VHE, the timer context save which reads CNTP_CVAL_EL0 under the new TGE/E2H, and the EL1 sysreg restore. Add an explicit isb() at each of the two deactivate sites. The practical impact today is bounded: HCR_EL2.E2H does not toggle in either path, and the trap bits being changed primarily affect EL1&0 behaviour. But the architectural rule should be honoured. Note that write_sysreg_hcr() itself already issues isb() on the Ampere errata path (sysreg.h), confirming the architectural expectation; the fast path optimises that away. The fix is at the call sites rather than inside write_sysreg_hcr() because the macro has many users (e.g. the activate path, at.c, hardirq.h, ptrauth alternatives) where the immediately-following code either reaches ERET or has another CSE; making the macro emit an unconditional ISB would impose unnecessary cost on those well-formed users. Fixes: 9404673293b0 ("KVM: arm64: timers: Correctly handle TGE flip with CN= TPOFF_EL2") Signed-off-by: Fuad Tabba --- arch/arm64/kvm/hyp/nvhe/switch.c | 11 +++++++++++ arch/arm64/kvm/hyp/vhe/switch.c | 11 +++++++++++ 2 files changed, 22 insertions(+) diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/swi= tch.c index 8d1df3d33595..9d7ead5a5503 100644 --- a/arch/arm64/kvm/hyp/nvhe/switch.c +++ b/arch/arm64/kvm/hyp/nvhe/switch.c @@ -105,6 +105,17 @@ static void __deactivate_traps(struct kvm_vcpu *vcpu) __deactivate_traps_common(vcpu); =20 write_sysreg_hcr(this_cpu_ptr(&kvm_init_params)->hcr_el2); + /* + * MSR HCR_EL2 is not self-synchronising. Per ARM ARM K1.2.4 p.K1-16823 + * and B2.6.1 p.B2-297, a Context Synchronisation Event is required + * between an HCR_EL2 write and any subsequent direct register access at + * the same EL that depends on the new value being in effect. + * The activate_traps path falls through to ERET (a CSE), but the + * deactivate path still executes further EL2 sysreg work (CPTR/VBAR + * writes below) before any natural CSE, so make the synchronisation + * explicit. + */ + isb(); =20 __deactivate_cptr_traps(vcpu); write_sysreg(__kvm_hyp_host_vector, vbar_el2); diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switc= h.c index 9db3f11a4754..140d3bcb5651 100644 --- a/arch/arm64/kvm/hyp/vhe/switch.c +++ b/arch/arm64/kvm/hyp/vhe/switch.c @@ -149,6 +149,17 @@ static void __deactivate_traps(struct kvm_vcpu *vcpu) ___deactivate_traps(vcpu); =20 write_sysreg_hcr(HCR_HOST_VHE_FLAGS); + /* + * MSR HCR_EL2 is not self-synchronising. Per ARM ARM K1.2.4 p.K1-16823 + * and B2.6.1 p.B2-297, a Context Synchronisation Event is required + * between an HCR_EL2 write and any subsequent direct register access at + * the same EL that depends on the new value being in effect. + * The activate_traps path falls through to ERET (a CSE), but the + * deactivate path still executes further EL2 sysreg work (CPTR/VBAR + * writes below) before any natural CSE, so make the synchronisation + * explicit. + */ + isb(); =20 if (has_cntpoff()) { struct timer_map map; --=20 2.54.0.545.g6539524ca2-goog From nobody Wed Jun 17 04:03:52 2026 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 938003EDAAE for ; Tue, 28 Apr 2026 10:30:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372216; cv=none; b=SS+QNVsx5eeoed6rmHLX//XlyNosPXV3BfucBNXE1twRV71+riOYuoJj0J0KYkGk+cVEQ7GcHmfNGGi/PY97mKIibe8ARkZoaDYynT2qIk9+emEKaNk4d9yUCK71MBqdeUHErC8bgsJtuIKyy5MSxtBfCjvMQqHjjjFC28QELTI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372216; c=relaxed/simple; bh=ZtY1NVCPXnAC9eiQixJVX87FIa55uNvzITzHg3dFSas=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=iWtkCiSEGrYBCyU4qywcn+pcxp3Re6l3yw6sR7CD1ws1hcJdSKjaNw6HXowzPquBaTpsjjwGVDpxPMhv8gj4N1DLCft14vBJGAG7Sv0act1Pga2fd4dOFuVZJhZCPKPX8qNn9zP0+WX5wdJiYXSl11GQV7eD00w5cotsT+wLCZE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=g0YtYvfw; arc=none smtp.client-ip=209.85.128.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="g0YtYvfw" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-4836abfc742so97351335e9.0 for ; Tue, 28 Apr 2026 03:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777372213; x=1777977013; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=2V4DeFz5zQx5vHTeG+ccViUA0qR3iKjsW9CqkQ1XIv0=; b=g0YtYvfw3M4xhY2/m2mai5WlFCxP5evLqDw2vnCL2sHBh7h46KHac7oN8Zd8pLGm6u Qzb+TkZg5u7JeM60wlE8CkCs0GV6lbtbnRCO+F5wXapQzsxr6TpGVWuTXyc9T8F0snrq WMbwwRGpAkOPlTiSYzTI0BWkYjQTU+dhgXuRZqMGJtUDUQfJE8Xfsq3KK1UJaNE4HQi2 6ZRf4kBcmB62t5Gb9qLFLnml9JTlsCtbicmdE3eBt4PZbs+h/vQ4BnvZLsDxyEZEEyIH Uu/c0hadcWACa48idsfjJnuqEbFT+VGEIhXVazejCyfxL1cNwkux/xcEq8cxs+crQc3y Le4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777372213; x=1777977013; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=2V4DeFz5zQx5vHTeG+ccViUA0qR3iKjsW9CqkQ1XIv0=; b=ijpXKDoaMbzexE+HX37ukHGjjPQkFIdX+y5fUieyKECKhcqRDIwhUZr0UrhG8hXMY+ cZ78aifQU0GN+WTIHGthVM7sfa+LWgneyEF+DOJ08gTA5DkENHhUe+3TC/uz75mZKRzq kQcG0QsXXwPMthC08KUHOsJHGRwrKooE27MSDfJzSFejueo9wSsIZij50veVSBnTah+N +1gxHtc94BQK32iiIZNblhflwhaebNpasd/rAIdy9pndK/inZ5zG3osAHJuAKlXgwyX6 mMxzK/leb60u90kCG0jBgCUjXJyVhdj//4b1YJE+aWmsHa+AfDZZamwo8O5l26KagaoX EkJg== X-Forwarded-Encrypted: i=1; AFNElJ9pUgh9y/GCmWEQu8bq29BXF35K+x5wHMNT7gwAualVsBUXkh37/oM1DRxHNaj35BPJcC3gJSRiJQyOUDw=@vger.kernel.org X-Gm-Message-State: AOJu0YxK/m/4Zq4sol12smDOE2puA6rDZNAJyapJq1lKo+jLe6Td8yup W6aN//E1cvEulL7ZQYy9DfQ5QEDvZcEf/vXPHrpeXDlo/eT8g3/VwxzUueOeBUDhvu1/Uu3Olpm SVQ== X-Received: from wmpc9.prod.google.com ([2002:a05:600c:4a09:b0:48a:54ff:28b2]) (user=tabba job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:c177:b0:48a:5301:bb5c with SMTP id 5b1f17b1804b1-48a77b12a49mr34221165e9.16.1777372212793; Tue, 28 Apr 2026 03:30:12 -0700 (PDT) Date: Tue, 28 Apr 2026 11:30:03 +0100 In-Reply-To: <20260428103008.696141-1-tabba@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260428103008.696141-1-tabba@google.com> X-Mailer: git-send-email 2.54.0.545.g6539524ca2-goog Message-ID: <20260428103008.696141-4-tabba@google.com> Subject: [PATCH 3/8] KVM: arm64: Guard against NULL vcpu on VHE hyp panic path From: Fuad Tabba To: maz@kernel.org, oliver.upton@linux.dev Cc: james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, qperret@google.com, vdonnefort@google.com, tabba@google.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On VHE, __hyp_call_panic() unconditionally calls __deactivate_traps(vcpu) on the vcpu pointer read from host_ctxt->__hyp_running_vcpu. That pointer is cleared after every guest exit (and is never set when no guest is running), so an unexpected EL2 exception landing in _guest_exit_panic, e.g. via the el2t*_invalid / el2h_irq_invalid vectors - reaches this function with vcpu =3D=3D NULL. __deactivate_traps() then dereferences vcpu via ___deactivate_traps() -> vserror_state_is_nested() -> vcpu_has_nv() -> vcpu->arch.features, faulting inside the panic handler and obscuring the original failure. The nVHE counterpart (hyp_panic() in arch/arm64/kvm/hyp/nvhe/switch.c) already guards its vcpu-using cleanup with "if (vcpu)"; mirror that here. sysreg_restore_host_state_vhe() and __hyp_do_panic() do not depend on vcpu and continue to run unconditionally, preserving panic forensics. The trailing panic("...VCPU:%p", vcpu) prints "(null)" safely via printk's %p handling. Fixes: 6a0259ed29bb ("KVM: arm64: Remove hyp_panic arguments") Signed-off-by: Fuad Tabba --- arch/arm64/kvm/hyp/vhe/switch.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switc= h.c index 140d3bcb5651..8912863cc238 100644 --- a/arch/arm64/kvm/hyp/vhe/switch.c +++ b/arch/arm64/kvm/hyp/vhe/switch.c @@ -674,7 +674,8 @@ static void __noreturn __hyp_call_panic(u64 spsr, u64 e= lr, u64 par) host_ctxt =3D host_data_ptr(host_ctxt); vcpu =3D host_ctxt->__hyp_running_vcpu; =20 - __deactivate_traps(vcpu); + if (vcpu) + __deactivate_traps(vcpu); sysreg_restore_host_state_vhe(host_ctxt); =20 panic("HYP panic:\nPS:%08llx PC:%016llx ESR:%08llx\nFAR:%016llx HPFAR:%01= 6llx PAR:%016llx\nVCPU:%p\n", --=20 2.54.0.545.g6539524ca2-goog From nobody Wed Jun 17 04:03:52 2026 Received: from mail-wr1-f74.google.com (mail-wr1-f74.google.com [209.85.221.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A75AB3EE1E6 for ; Tue, 28 Apr 2026 10:30:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372217; cv=none; b=EKpwmRJO2BL3uWNGPJQjYJb+QPuYYBqlakIyfkhj1BRoTcJ3VrdvjqI6hPbfVhOC4dF7AhlBZzm4MNgEh/7mmWGMlbw3n692cEPvsrt1bTyxYhzBZsywxQ1b5Ki5Je1vWmJxLozs658O0hE40UyXOj1ZNzP5QPLU7SG5LmbL0Ck= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372217; c=relaxed/simple; bh=pWsb4LXB9ThVgvldcf9CnL/d7vmpsynGuhGjfwFYyJI=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=ufxAYeubiM+ABR5DARGIaRsPZNy68TWWBIobmAYk5tEyOCAZRXxep2tR1GC+Sb28ZXVd0lj+hcSUI1QXReGN6TEWVHKGqeTkg2W/mxBm/fk0os2IgUzzwhmhX5YJbUPzbV9deN/fuykSn3ZeAizV9FiOB7QkYf+s+Vde+3DvUF8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=h00sOX+p; arc=none smtp.client-ip=209.85.221.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="h00sOX+p" Received: by mail-wr1-f74.google.com with SMTP id ffacd0b85a97d-43d121c4271so7765688f8f.3 for ; Tue, 28 Apr 2026 03:30:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777372214; x=1777977014; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=GmmNYOk+NsHl9ECni3ZP17QcbrO127/DqtR017v434Y=; b=h00sOX+pg51AOtlp5hCgDgF+KVHtVyFQ+MoPG9ZPL840gpmouGfh4k2RMP8AOHwCVK Wifu5VudsNXcBTeodRMzowUtoc4MgJgSUeBY5McksMZg1bOtU91PD7VOLO3nqBCvosaE v8mo2OlikjdHPTKAFBCjSktEHhtg0dm1QskLJ6QY1N0VOHDazfCK/JlqbKYdVGIDWYRS ZxVbpjHO3fjJmFnRSF93R787hp3X76UzH8YhANDO1ug5KWwsJF5LU1x/GJk9Z1ShAxuM Bvy7eoVKq50zmX4LOjMQfs0iZu7ePuVdpLaZF+LTwaaSoCA5c/5Kw3zp0tD4TVSY2m2e gs1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777372214; x=1777977014; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=GmmNYOk+NsHl9ECni3ZP17QcbrO127/DqtR017v434Y=; b=XmlaKLdZuCpEFWJ1MS8KdVFKfnXO0UMemRBRLXTLeOQ6uiSOjmW2YE9keOAHTYCIAx xkFVEjBaian9F9N6V7rIf6GnyLYNQJ1jqrWC8a6XGdJWLVxixs3C//jWa2eXwKK7woVk saufMVlZxNvEt863puRSw4aVIUGbu39ea7NG9CNaML3EZCGfimT8ctpFblp32HtuEBbU au/uYRg5l5XpQ3iiC+DS6nod7iAHtLX41J/GG064mOwfeSLG5dS5xLRLFhqhvGGWhF+o TOA4nSEW01Q/c/XAIvgr3ZPaGF+2S5LNQuJnovUp9JqfgWB7izqXFGHuyPnkTjIpX2fQ bg/A== X-Forwarded-Encrypted: i=1; AFNElJ/4txHYwGZPWE22sL9KZLTTD1PRZeX2YHANatagHo2+8DT1Zg3dw0zIp2BLZQuYqxqMKb4oba+9VTXSZag=@vger.kernel.org X-Gm-Message-State: AOJu0YxxZYIwtq2xCS5mKNftrEXiGiEQ4Qs+63O1PlRoM+c897+o68dc DoNspLr5Tegq1y7fyeffpvMQsD5Uu49H3cMYbXK6mUlPbSKFoibEvqytw9dnZArW02XQlCd9XL7 lEQ== X-Received: from wrrn5.prod.google.com ([2002:adf:fe05:0:b0:439:d2b7:2393]) (user=tabba job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:26c6:b0:43f:e7c9:2402 with SMTP id ffacd0b85a97d-4464761c29fmr4504996f8f.3.1777372213972; Tue, 28 Apr 2026 03:30:13 -0700 (PDT) Date: Tue, 28 Apr 2026 11:30:04 +0100 In-Reply-To: <20260428103008.696141-1-tabba@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260428103008.696141-1-tabba@google.com> X-Mailer: git-send-email 2.54.0.545.g6539524ca2-goog Message-ID: <20260428103008.696141-5-tabba@google.com> Subject: [PATCH 4/8] KVM: arm64: Fix __deactivate_fgt macro parameter typo From: Fuad Tabba To: maz@kernel.org, oliver.upton@linux.dev Cc: james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, qperret@google.com, vdonnefort@google.com, tabba@google.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" __deactivate_fgt() declares its first parameter as "htcxt" but the body references "hctxt". The parameter is unused; the macro silently captures "hctxt" from the enclosing scope. Both existing callers (__deactivate_traps_hfgxtr() and __deactivate_traps_ich_hfgxtr()) happen to define a local "struct kvm_cpu_context *hctxt", so the macro works by coincidence. A future caller without an "hctxt" local in scope, or naming it differently, would compile but bind to the wrong context. Align the parameter name with the sibling __activate_fgt() macro. The "vcpu" parameter remains unused in the body, kept for API symmetry with __activate_fgt() (which uses it). Fixes: f5a5a406b4b8 ("KVM: arm64: Propagate and handle Fine-Grained UNDEF b= its") Signed-off-by: Fuad Tabba --- arch/arm64/kvm/hyp/include/hyp/switch.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/i= nclude/hyp/switch.h index 98b2976837b1..bf0eb5e43427 100644 --- a/arch/arm64/kvm/hyp/include/hyp/switch.h +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h @@ -245,7 +245,7 @@ static inline void __activate_traps_ich_hfgxtr(struct k= vm_vcpu *vcpu) __activate_fgt(hctxt, vcpu, ICH_HFGITR_EL2); } =20 -#define __deactivate_fgt(htcxt, vcpu, reg) \ +#define __deactivate_fgt(hctxt, vcpu, reg) \ do { \ write_sysreg_s(ctxt_sys_reg(hctxt, reg), \ SYS_ ## reg); \ --=20 2.54.0.545.g6539524ca2-goog From nobody Wed Jun 17 04:03:52 2026 Received: from mail-wr1-f73.google.com (mail-wr1-f73.google.com [209.85.221.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 029AD3EF64C for ; Tue, 28 Apr 2026 10:30:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372220; cv=none; b=O2J28xvAUeFn8iapzHdhW8RZCkLuoCZTHgHwjppEnUfPRNO24+pijZWdHiBXXbZqmEt3aSGL0ujQe3MTMUPLyuylffQSGWSAJjUi3QMB0JrtkKiEF6SbC9UolIiosyxqDhQKjfMU9HstwhaodYEpB3BAOvPCLJrneXBLV/LbFTU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372220; c=relaxed/simple; bh=7tTHLjAgEKGsBTyH0lVNois2KVPH84/6SrQTXYZUwfs=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=MkPx9mzPLIIEfPlYSDog53WUj1TJOqUkIw3aKJpUfsKfdgYXLy/gx77CgH1CFNRMR19ulO3n1pHLAC33n2EeHwUfdbqZyYvwz4f7guh9yaPmoyQ2f1S/6139t2jRCOWe2tVOlyah50O81UjFywNvzJodas6HQxZRM4+Sl16Tygk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Ys3e/gBW; arc=none smtp.client-ip=209.85.221.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Ys3e/gBW" Received: by mail-wr1-f73.google.com with SMTP id ffacd0b85a97d-44696b11265so546982f8f.0 for ; Tue, 28 Apr 2026 03:30:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777372215; x=1777977015; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=dYUkAwnLJFRq1L2KWhPMCbl0fLNqeKRbzrqZSKodisQ=; b=Ys3e/gBWC2qFncrd+dQKPstgSIZW5+MrhnxoUEbj6APnNGSmKeDC7bpGyPbckC7kqg ierlz1W3pYTy7QAM3pAo4YYcyB54J4dJ9QUjUCHqY+DNOh7JB+VaD6yTsXM068Bo/1Ip D4gZ/rRgsgPC3AwS1nRxBqNV1S71xK/nHStSi+xSIRxVyEuEzx5vjZXEMKFhOwojXyz7 PBlnaeprtUF6hico4N5WLQkThDTVC6zLQ7jq2Lmr1BzWxCFRwtBfVN9CTUS+BZr0Hctw VAmLBN7YiSPgxk8XZxqiL2DwmpqsqxPRRbjpC3AoOAfva29v+1eTrH+RS97aJKX8XwQ6 Vcbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777372215; x=1777977015; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dYUkAwnLJFRq1L2KWhPMCbl0fLNqeKRbzrqZSKodisQ=; b=PPKevuldKVBvTp43MhpF5BwZLb9mfvNR66tXgRXMYD5T/Ah0qBpmt4OPKKb+dSJsDC dlBkU5kQ0AMHEe3u9jihjzPA43jcxm1V/ht36ZZ5kpQqLh2iFr8UmUs11Erzd82tJVkZ ctLSsxXwTxQZu/V8TOzeXfdd/09n9/H8SWsLNhtS4caMXqlxklgNIU6yK9nPZCBGG9/E bA84VJ+QPLn7N8YMhKE1koKeqQ+U8aMsbWoWP30zxmOdkyqmUhIkF9j/xjFP1M74WVTU snrhnbkGE+dfN/7QnB25jd2eZNgc1UVn44m92skjCAufB930wYENoaA8qPwL9Ej5qfsw qfRQ== X-Forwarded-Encrypted: i=1; AFNElJ/oAf04N0njVxMpB+OIjbVumayTIZx1xuBV+/VqLCMKLG2YB9gEYCP1JovllFDLnhr2DwPbaFA5acC66U8=@vger.kernel.org X-Gm-Message-State: AOJu0YzCAgr6xvmNaAliznrWHEDytdsWisbB7J8e1XRVmkQ1EAVme4l/ gwNuakxuB4RSnL3yEqge8MI/fMZdt4n41clL3HH/AaCLbTjsXXtVaGwLhwPD71eTW3GrmZlEwJK rpw== X-Received: from wrou16.prod.google.com ([2002:adf:ed50:0:b0:445:adc5:751d]) (user=tabba job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:3b15:b0:489:1f3e:5f6f with SMTP id 5b1f17b1804b1-48a77ae5502mr42869535e9.12.1777372215150; Tue, 28 Apr 2026 03:30:15 -0700 (PDT) Date: Tue, 28 Apr 2026 11:30:05 +0100 In-Reply-To: <20260428103008.696141-1-tabba@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260428103008.696141-1-tabba@google.com> X-Mailer: git-send-email 2.54.0.545.g6539524ca2-goog Message-ID: <20260428103008.696141-6-tabba@google.com> Subject: [PATCH 5/8] KVM: arm64: Propagate stage-2 map failure on host->guest share From: Fuad Tabba To: maz@kernel.org, oliver.upton@linux.dev Cc: james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, qperret@google.com, vdonnefort@google.com, tabba@google.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" __pkvm_host_share_guest() mutates the host vmemmap for every page in the range (sets PKVM_PAGE_SHARED_OWNED and increments host_share_guest_count) and then calls kvm_pgtable_stage2_map() to install the guest stage-2 mapping. The stage-2 map's return value was wrapped in WARN_ON() and otherwise discarded. At EL2 in nVHE/pKVM, WARN_ON() is not warn-and-continue: it expands to a BRK that enters the invalid-host-el2 vector and branches to hyp_panic(), declared __noreturn. WARN_ON of a reachable failure at EL2 is a panic primitive, not a debug aid. kvm_pgtable_stage2_map() can fail in reachable ways: the stage-2 walker requests fresh pages from the caller's memcache and returns -ENOMEM when the memcache is exhausted mid-walk. The host controls the vcpu memcache via the topup interface, so an under-provisioned share request converts a recoverable error into a fatal hyp panic. Capture the stage-2 map return value and propagate it. The walker may have installed leaf entries for some pages in the IPA range before failing, so unmap the range to clear any partial mappings; otherwise the guest would retain stage-2 access to pages the host is about to reclaim. Then roll back the host vmemmap mutations from the forward pass: the forward pass increments the count by 1 on every page, and the only forward state transition is OWNED -> SHARED_OWNED (the count 0 -> 1 transition). The reverse pass decrements the count and, if it drops back to zero, restores PKVM_PAGE_OWNED. Pages already SHARED_OWNED with other sharers (count > 1 after the forward pass) only need the count decremented. Fixes: d0bd3e6570ae ("KVM: arm64: Introduce __pkvm_host_share_guest()") Signed-off-by: Fuad Tabba --- arch/arm64/kvm/hyp/nvhe/mem_protect.c | 30 ++++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvh= e/mem_protect.c index 28a471d1927c..7044913a0758 100644 --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c @@ -1458,9 +1458,33 @@ int __pkvm_host_share_guest(u64 pfn, u64 gfn, u64 nr= _pages, struct pkvm_hyp_vcpu page->host_share_guest_count++; } =20 - WARN_ON(kvm_pgtable_stage2_map(&vm->pgt, ipa, size, phys, - pkvm_mkstate(prot, PKVM_PAGE_SHARED_BORROWED), - &vcpu->vcpu.arch.pkvm_memcache, 0)); + ret =3D kvm_pgtable_stage2_map(&vm->pgt, ipa, size, phys, + pkvm_mkstate(prot, PKVM_PAGE_SHARED_BORROWED), + &vcpu->vcpu.arch.pkvm_memcache, 0); + if (ret) { + /* + * Stage-2 map can fail mid-walk (e.g. -ENOMEM from the + * memcache), leaving partial leaf entries installed in the + * guest stage-2. Tear them down before rolling back host + * bookkeeping; otherwise the guest would retain access to + * pages the host is about to reclaim as PKVM_PAGE_OWNED. + */ + kvm_pgtable_stage2_unmap(&vm->pgt, ipa, size); + + /* + * Roll back the host vmemmap mutations applied above. A page + * whose host_share_guest_count is now 1 was PKVM_PAGE_OWNED + * before this call (count 0->1, state OWNED->SHARED_OWNED); + * undo both. A page with count > 1 was already + * PKVM_PAGE_SHARED_OWNED with other sharers; only the count + * needs to be decremented. + */ + for_each_hyp_page(page, phys, size) { + page->host_share_guest_count--; + if (!page->host_share_guest_count) + set_host_state(page, PKVM_PAGE_OWNED); + } + } =20 unlock: guest_unlock_component(vm); --=20 2.54.0.545.g6539524ca2-goog From nobody Wed Jun 17 04:03:52 2026 Received: from mail-wr1-f73.google.com (mail-wr1-f73.google.com [209.85.221.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D13AF3EF658 for ; Tue, 28 Apr 2026 10:30:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.73 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372220; cv=none; b=C4eCHMjwE4Pk0eTFK6Ju0jfzeqbhPevtYnxV/CO16lPEPOUIRGp+koUTT/GNVjP4hRiuDG/TmE88iIG9IYeWcI2zb2V7groyVf98OQbKY1VOsR5k5ufcNzg2GHkcpMkCA2PXPqrm5xBe6gpdcEeCQS4T43Y1iPoCKwtZazmjUm8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372220; c=relaxed/simple; bh=Kn1z2vYj7fovu9i0b/eXjuXPOoyK7xrPU6Ci1PU8424=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=VQ14Ak7jXnlqSxwWpse9a+nmhqhc96FzCkg6bD4AFhnhaXekAdosfk/xpnklJr/x45iOiF2TeKjSZ2ix+swEDxsJ6Y09JebGuMvjq4jS0Y28KK4evzFDmC2DplE09j6PIiIJXJms6B7Jthhqua12cCrMJtkmHPzaWBtumc71ag8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=IcxpIaqM; arc=none smtp.client-ip=209.85.221.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="IcxpIaqM" Received: by mail-wr1-f73.google.com with SMTP id ffacd0b85a97d-43d103e46c3so7798667f8f.3 for ; Tue, 28 Apr 2026 03:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777372216; x=1777977016; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=YBzgBVDAjOycqgcIzeu+4bme8jBbglGvTuoHc/CuC0c=; b=IcxpIaqMFowOy/eZe/evndXaWi3CfzLRByj8yFKega1WSRaCQ1rWf4DbxmaMwtETca ElVrnwAadN/QMWZBysrHAm9XY72PixtdY1b+nmiNQwqXoXMtaB5om0ApkInS0pAcRhF8 qmM5nzFiZyy68xO9H/zBucET+N2TPK4MPXRTXnz+atJWjZM3i/STfwvxZKleKuSuuLs6 Hk4YF1QyIg//7sRyT5d6nfRnE5gNPOnyiaXnlCxhL8PwoqWQOw6EdbZzyTiUFqIYX+QV zFZ6EGRQrqwv51Fi4vcQwjG+2e2ApJq4ynT1vnzj5cJg2hn7ip9gmlB7WnRB8F/vPbNT iZRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777372216; x=1777977016; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=YBzgBVDAjOycqgcIzeu+4bme8jBbglGvTuoHc/CuC0c=; b=k90nLGjiFbmj8nsnykSCpJJrurpE+iLmAaLCcM8LW+6hVejtL7BNTDJtd3iUmFMqW9 FavZMcE5Zxk346bXS21XPK219VYQnq6isy0eIWxb71aSoebbpP4ouzByPzTqmszfiA19 XDYBtUG8DI0T/3CN3UgUDLrOtxjkidftMQJNyq/rRCFcttl57iAmJ+Ci+T3hD/olKV8U Gl1WlbX9llVDMkMPpnZpXWyA+SWxZxBe2tUhQ9l+t7tURvfDRNn9+YYlDiyeOL9+QWdt 4SyYSWVmm4q+QvfApPLvQyb7e7VzwA3/3FpW38pzxLMPoCJBlS84aMVQeChw3R/fj/ai J8wg== X-Forwarded-Encrypted: i=1; AFNElJ8srB/y4QbphBDX0lA3i/1C7yWmajIZuWaMBwXfxEwjghv29q+7GVirY8YDXPtA7OG+NXALrzyVwdNu2bs=@vger.kernel.org X-Gm-Message-State: AOJu0YyqEYg1BR3UdPvLM2HCliK99MtTUa8RaW4qh+3K77aXp0ZzJYq0 47zqG82ksl+7lgO3MlnFDydto/D1uTm29qYmNjku+7lAzd7R1rtCQDl1mIKW4O28DDqjsPRuTYE 1eA== X-Received: from wrvw10.prod.google.com ([2002:a5d:544a:0:b0:43e:a8da:c95a]) (user=tabba job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:3109:b0:43d:7aa8:f64e with SMTP id ffacd0b85a97d-44649c995b6mr4775338f8f.32.1777372216035; Tue, 28 Apr 2026 03:30:16 -0700 (PDT) Date: Tue, 28 Apr 2026 11:30:06 +0100 In-Reply-To: <20260428103008.696141-1-tabba@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260428103008.696141-1-tabba@google.com> X-Mailer: git-send-email 2.54.0.545.g6539524ca2-goog Message-ID: <20260428103008.696141-7-tabba@google.com> Subject: [PATCH 6/8] KVM: arm64: Propagate stage-2 map failure on host->guest donation From: Fuad Tabba To: maz@kernel.org, oliver.upton@linux.dev Cc: james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, qperret@google.com, vdonnefort@google.com, tabba@google.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" __pkvm_host_donate_guest() flips the host stage-2 PTE for the donated page to a non-valid annotation (KVM_HOST_INVALID_PTE_TYPE_DONATION, owner =3D PKVM_ID_GUEST) via host_stage2_set_owner_metadata_locked() and then calls kvm_pgtable_stage2_map() to install the matching guest stage-2 mapping. The map's return value was wrapped in WARN_ON() and otherwise discarded. At EL2 in nVHE/pKVM, WARN_ON() is not warn-and-continue: it expands to a BRK that enters the invalid-host-el2 vector and branches to hyp_panic(), declared __noreturn. WARN_ON of a reachable failure at EL2 is a panic primitive, not a debug aid. kvm_pgtable_stage2_map() can fail in reachable ways even at PAGE_SIZE granularity: __pkvm_host_donate_guest() verifies PKVM_NOPAGE for the guest IPA before the map, meaning no valid stage-2 entry exists. The walker must allocate new page-table pages from the vcpu memcache to install the mapping, returning -ENOMEM if exhausted. The host controls the vcpu memcache via the topup interface, so an under-provisioned donation request converts a recoverable error into a fatal hyp panic. Capture the stage-2 map return value and propagate it. The walker may have installed partial leaf entries for the IPA before failing, so unmap the range to clear them; otherwise the guest would retain stage-2 access to a page the host is about to reclaim as PKVM_PAGE_OWNED. Then roll back the host stage-2 mutation: the only forward mutation is host_stage2_set_owner_metadata_locked() flipping the host vmemmap from PKVM_PAGE_OWNED to PKVM_NOPAGE and the host stage-2 PTE from idmap to invalid+annotation. host_stage2_set_owner_locked(_, _, PKVM_ID_HOST) restores both. The rollback calls host_stage2_set_owner_locked() under WARN_ON. This is the correct use: host_stage2_set_owner_metadata_locked() just wrote the host leaf PTE as an invalid+annotation entry, so the reverse idmap rewrite cannot require new page-table allocation =E2=80=94 it rewrites the leaf in-place. The WARN_ON asserts an impossible state under correct EL2 execution, semantically distinct from the misuse being fixed. Fixes: 1e579adca177 ("KVM: arm64: Introduce __pkvm_host_donate_guest()") Signed-off-by: Fuad Tabba --- arch/arm64/kvm/hyp/nvhe/mem_protect.c | 27 ++++++++++++++++++++++++--- 1 file changed, 24 insertions(+), 3 deletions(-) diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvh= e/mem_protect.c index 7044913a0758..b8c57a95e9bf 100644 --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c @@ -1391,9 +1391,30 @@ int __pkvm_host_donate_guest(u64 pfn, u64 gfn, struc= t pkvm_hyp_vcpu *vcpu) meta =3D host_stage2_encode_gfn_meta(vm, gfn); WARN_ON(host_stage2_set_owner_metadata_locked(phys, PAGE_SIZE, PKVM_ID_GUEST, meta)); - WARN_ON(kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys, - pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_OWNED), - &vcpu->vcpu.arch.pkvm_memcache, 0)); + ret =3D kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys, + pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_OWNED), + &vcpu->vcpu.arch.pkvm_memcache, 0); + if (ret) { + /* + * Stage-2 map can fail mid-walk (e.g. -ENOMEM from the + * memcache), leaving partial leaf entries installed in the + * guest stage-2. Tear them down before rolling back the host + * stage-2; otherwise the guest would retain access to a page + * the host is about to reclaim as PKVM_PAGE_OWNED. + */ + kvm_pgtable_stage2_unmap(&vm->pgt, ipa, PAGE_SIZE); + + /* + * Roll back the donation annotation applied above by + * host_stage2_set_owner_metadata_locked() (host vmemmap + * PKVM_NOPAGE -> PKVM_PAGE_OWNED, host stage-2 PTE + * invalid+annotation -> idmap). The leaf PTE was just + * installed by the forward call, so reinstating the idmap + * rewrites it without needing fresh page-table pages from + * host_s2_pool. + */ + WARN_ON(host_stage2_set_owner_locked(phys, PAGE_SIZE, PKVM_ID_HOST)); + } =20 unlock: guest_unlock_component(vm); --=20 2.54.0.545.g6539524ca2-goog From nobody Wed Jun 17 04:03:52 2026 Received: from mail-wr1-f74.google.com (mail-wr1-f74.google.com [209.85.221.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BD34E3EFD1F for ; Tue, 28 Apr 2026 10:30:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372221; cv=none; b=BWRaP+OkqlOMVvFAI2JoRb9gP7TpPs8rNU5o84Wwy/wXdsX2M7CmlNklIwHOf9JBTeoVaDeGqgTniKp8xhD4PAv4Eexw5FYZiYCzuctEKlCEhOVEFGuxaIT8ONFNzEc6V+OfmOTfNjmbVhPml9HFlCZyjWODxUY0LIFS67r15bs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372221; c=relaxed/simple; bh=W+xyFXpoTcAVO81+t0rS/9kkHRryS/Ehmc0XpyAYi18=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=tYuvS8karqT4TZ/T4Dt6ajx/Nbkxb/qmk35wbfO4kJbKmRWu7Mw/g/iECc4o92j6PV+7ARHjqAvj0wO2j3JuV84YdwpAq8nK2X/FVxrQEtY5VEozsRb93YbbP6pUKp7vVrGBRn7VhOVxLYTcCXaNCIaJx/rVIpuAoY66RLDZkbs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Q9Ky5o3m; arc=none smtp.client-ip=209.85.221.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Q9Ky5o3m" Received: by mail-wr1-f74.google.com with SMTP id ffacd0b85a97d-43fe4674d3eso9440476f8f.1 for ; Tue, 28 Apr 2026 03:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777372217; x=1777977017; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=WeB2s/TMGphof+D0QG47UlxNIiB+La++tp7fDFhGihQ=; b=Q9Ky5o3mI4mPyn4KuWIfqaZXoUTaKCq5yygORGX7VcU1M7czDhCiS4d1tmHROyy7Q8 JLDMWch/VXJ1OSX6BpS/cuPhxVquUi1BJb/5E3tymhpRwBxVQKZdu9UbFGuICDsALzB4 J/cZWRFOeOD2/QPDx9xIsAnhPKnbNsul91mw6jXgUJwdJ9/V0gfeXCy5uplnUS/uTbEG N5sFb/+wpmhYxkLjlMml0WuvDtgxZXDiwg0HwFFYMxiogFXq1YHHETtDkoGzPIRno6Pn GCVhYSJU3Qj9s5u3YDZlEONBenHgTDcmd1RynTUtxVU+lq15+bUMYz+uBcXNPxgpI4FM ZHFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777372217; x=1777977017; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WeB2s/TMGphof+D0QG47UlxNIiB+La++tp7fDFhGihQ=; b=h6EDB8CU7H5ui0uAiR1fmcarPJepWqRgevzL6Qt/93Q8DXINKEQAqEkr6PYf2nfBep 3cGIHGh+SnHfW8SKCP9yGAf3pAisIFkBvP+DTjxOZc55NibvOR3XKIqlZjGLkEA+bW4p f5hN8QJlqBDbuxVq1LXxPRC/D7O/UCC39l8aeAF/916edK2fAHNE7Lb4RpQtjS7tSXPh M/QjRCRaRe7007lOfdggqpyaV2qW13crgC806drTCKYICINM0IK/BFv6WXUkMhXKfODX JblaBAshcUvEYPb6uD5+KmLBsoFmD4hAlKgVtfjnhcOygQFSkeGbGmi2Ah43NYY7PFXe DGQw== X-Forwarded-Encrypted: i=1; AFNElJ9LFjNEOWEgdjpNCtH3V2j+BDpFFoDAqDTDgEC9AgLSeY21hIcgI6TUMpxXXGe7XNSy6gNE55FEYSO1lJw=@vger.kernel.org X-Gm-Message-State: AOJu0Yz7jAjz4i6nPZexNh/kzdcb2pkROjtinU9dx1nsJzG0VGlWLLVP 3LQQqbl3Q5z4R3vIxBXYsvJudmIAeCpdTTpJdtzlSqeQdxCMUUu9p1AEjPLrGVb3eg6U+YzW9QD 6rQ== X-Received: from wrdf9.prod.google.com ([2002:a5d:58e9:0:b0:43f:e626:ada7]) (user=tabba job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6000:1865:b0:43d:6e0:9458 with SMTP id ffacd0b85a97d-4464aa09351mr4498102f8f.39.1777372217076; Tue, 28 Apr 2026 03:30:17 -0700 (PDT) Date: Tue, 28 Apr 2026 11:30:07 +0100 In-Reply-To: <20260428103008.696141-1-tabba@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260428103008.696141-1-tabba@google.com> X-Mailer: git-send-email 2.54.0.545.g6539524ca2-goog Message-ID: <20260428103008.696141-8-tabba@google.com> Subject: [PATCH 7/8] KVM: arm64: Propagate stage-2 map failure on guest->host share From: Fuad Tabba To: maz@kernel.org, oliver.upton@linux.dev Cc: james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, qperret@google.com, vdonnefort@google.com, tabba@google.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" __pkvm_guest_share_host() updates the guest stage-2 PTE for a guest-OWNED page to PKVM_PAGE_SHARED_OWNED via kvm_pgtable_stage2_map() and then transitions the host vmemmap and stage-2 PTE to PKVM_PAGE_SHARED_BORROWED. The map's return value was wrapped in WARN_ON() and otherwise discarded. At EL2 in nVHE/pKVM, WARN_ON() is not warn-and-continue: it expands to a BRK that enters the invalid-host-el2 vector and branches to hyp_panic(), declared __noreturn. __pkvm_guest_share_host() calls get_valid_guest_pte() before the map, which verifies that a valid last-level (PAGE_SIZE) leaf PTE already exists for the IPA. Because the leaf and all intermediate tables are in place, the subsequent kvm_pgtable_stage2_map() replacing it cannot fail via -ENOMEM: no block to split, no new tables to install. The failure path is not currently reachable. Nevertheless, WARN_ON() on any fallible call is the wrong pattern at EL2: if the get_valid_guest_pte() precondition were ever relaxed, or the walker gained a new failure mode, the WARN_ON would convert a recoverable error into a fatal hyp panic. Capture the return value and propagate it. The unmap() is kept as a defensive guard for the currently unreachable failure path; no host-side unwinding is needed since the host vmemmap and stage-2 update is the next step and is correctly skipped on error. Fixes: 03313efed5e2 ("KVM: arm64: Implement the MEM_SHARE hypercall for pro= tected VMs") Signed-off-by: Fuad Tabba --- arch/arm64/kvm/hyp/nvhe/mem_protect.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvh= e/mem_protect.c index b8c57a95e9bf..6fb546af699f 100644 --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c @@ -979,10 +979,23 @@ int __pkvm_guest_share_host(struct pkvm_hyp_vcpu *vcp= u, u64 gfn) if (__host_check_page_state_range(phys, PAGE_SIZE, PKVM_NOPAGE)) goto unlock; =20 - ret =3D 0; - WARN_ON(kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys, - pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_SHARED_OWNED), - &vcpu->vcpu.arch.pkvm_memcache, 0)); + ret =3D kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys, + pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_SHARED_OWNED), + &vcpu->vcpu.arch.pkvm_memcache, 0); + if (ret) { + /* + * Stage-2 map can fail mid-walk (e.g. -ENOMEM from the + * memcache), leaving partial leaf entries in the guest + * stage-2 transitioned to PKVM_PAGE_SHARED_OWNED. Tear + * them down so the host does not see a partially-shared + * mapping it has not yet acknowledged via the host + * stage-2 update below. No host bookkeeping needs + * unwinding here: the only mutation prior to the failed + * map is the (now-discarded) guest stage-2 update itself. + */ + kvm_pgtable_stage2_unmap(&vm->pgt, ipa, PAGE_SIZE); + goto unlock; + } WARN_ON(__host_set_page_state_range(phys, PAGE_SIZE, PKVM_PAGE_SHARED_BOR= ROWED)); unlock: guest_unlock_component(vm); --=20 2.54.0.545.g6539524ca2-goog From nobody Wed Jun 17 04:03:52 2026 Received: from mail-wr1-f74.google.com (mail-wr1-f74.google.com [209.85.221.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 372263F074E for ; Tue, 28 Apr 2026 10:30:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372222; cv=none; b=J7WBUsIFm4XTNGTlAX5CVIqKedL5S+Nw1aZ/GUh1dn451YOo72xnWzg82f0LTyN+NnRn6VluRaCwEc7UApC7bJYh2lekxDB3V5X9jjDR5IjYpEkim37Ol4QZVmvMCMaLG7jOijOy3J0AnvUr4ZiAkTZ/kEHU+DRkvdgYffnmzvM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777372222; c=relaxed/simple; bh=maNkTII608MzcF1ju87MQQ+KK6PcKFHw8+zyZf9QEJg=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=JHSrnVBWzms8fsPiSJO0Oe0Bopx9RfHcMkZ6klOnIAbk69alLI78LGR9OdQcz4KPV6c7wvO4JQarBOgQYzadEVvidFS+mZScdseIAqQ7KIkwUw0YcVH5IwHGjXiwcWBXw+M4za6mSbVOkpyDZ9hz3TYPT8/H+BzC6A/E18tlaO4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=Ne6exxQs; arc=none smtp.client-ip=209.85.221.74 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--tabba.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Ne6exxQs" Received: by mail-wr1-f74.google.com with SMTP id ffacd0b85a97d-43ea7a5da57so9302299f8f.1 for ; Tue, 28 Apr 2026 03:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1777372218; x=1777977018; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=ZBFwe+kQ1OqLHi9s19ESuOVx/rJg9xLwA9cXX3TmEmg=; b=Ne6exxQsW1AzSFQgtqiRUTruJVnx+Y5U5Qom9+VmeEQU1n3QA/dZpGuhP3sJQLQbZ5 D/Kh7Wv6aVE0rtAx4+9/hGop2Oa6P0DmpnHlrCYrQ7+psbAS4XQkD1yPovw9GssfxCVV OXvNXm9ZC/GiXXLdAjjFWa4nnTi0b+wg/sZdwekl3YhGUfTMW9RLiF88jicrRSwpPAF5 py6yk/KURGDcESGa/jXcK7E41wAPkJu4LLALiq8NsNkg4hh9Y28pezhrNshIllK/kKyE 0TRWpGG06KnzX99qIyidlUnBjSMl0qt8AgiEiSq6eOUrlgaup5s6KHKKoNbzCDi9gJZp dhxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777372218; x=1777977018; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=ZBFwe+kQ1OqLHi9s19ESuOVx/rJg9xLwA9cXX3TmEmg=; b=Q7At/kk1FpxS+oSkQo7hNYJBNVFoiUdP+b5tk0ifplBzTGXb/isVfxMwSzgBdYP80x PjPwLg+i7aW7ep/Cpope7LWRC3EARmuzx5JwQhMvoqvOtZyQHrxJO4+p667ZBxpXZSk+ rL9pUTq6+vnfpbdtJ0cqn5MCbUY0PSxlltDZaQtpk7tk9vhBrFWoTwJ0BzMCiq1W3GEr Bw1LvLcjY3wXxj64MmYWn1hocPTgEq/DUj9uF6DptZqRFDI4H6d9j5MsWPyJTgyxNLrc 799jDXz9bG9WwbEo+ZFhSaoNfO03K19ZyL5IJxPmNyYa+YIDRvum7yc6VIeHKLSEBxiB nq0g== X-Forwarded-Encrypted: i=1; AFNElJ/ERvt7NYzFg2gDgIuAh9vXBbjzo/dy27zfQFma0GFgi3lJrITZa1yZc2tiISmS2or2C8DymcwBj1sRauo=@vger.kernel.org X-Gm-Message-State: AOJu0Yxg4Jn/C5cj0wzhJGb9VMyQ5L9sBTMfxS3nCzNBVWfaDffBMsZt g8PZuGc8Omh+1KPLltHuIR8Tg+6dB+mfdsvbzP+zDfty11KY1gmjfEzNVEEUGI2JPqEEG8yi19c /Ag== X-Received: from wmbjp7.prod.google.com ([2002:a05:600c:5587:b0:488:a71c:cf48]) (user=tabba job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:3b90:b0:488:a639:b772 with SMTP id 5b1f17b1804b1-48a77af5f04mr37827885e9.7.1777372218008; Tue, 28 Apr 2026 03:30:18 -0700 (PDT) Date: Tue, 28 Apr 2026 11:30:08 +0100 In-Reply-To: <20260428103008.696141-1-tabba@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260428103008.696141-1-tabba@google.com> X-Mailer: git-send-email 2.54.0.545.g6539524ca2-goog Message-ID: <20260428103008.696141-9-tabba@google.com> Subject: [PATCH 8/8] KVM: arm64: Propagate stage-2 map failure on guest->host unshare From: Fuad Tabba To: maz@kernel.org, oliver.upton@linux.dev Cc: james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, qperret@google.com, vdonnefort@google.com, tabba@google.com, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, stable@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" __pkvm_guest_unshare_host() re-acquires exclusive guest ownership of a page by (i) annotating the host stage-2 PTE via host_stage2_set_owner_metadata_locked(), (ii) mapping the page in the guest stage-2 as PKVM_PAGE_OWNED via kvm_pgtable_stage2_map(), and (iii) restoring host ownership via host_stage2_set_owner_locked(). The map's return value was wrapped in WARN_ON() and otherwise discarded. At EL2 in nVHE/pKVM, WARN_ON() is not warn-and-continue: it expands to a BRK that enters the invalid-host-el2 vector and branches to hyp_panic(), declared __noreturn. __pkvm_guest_unshare_host() calls get_valid_guest_pte() before the map, which verifies that a valid last-level (PAGE_SIZE) leaf PTE already exists for the IPA. Because the leaf and all intermediate tables are in place, the subsequent kvm_pgtable_stage2_map() replacing it cannot fail via -ENOMEM: no block to split, no new tables to install. The failure path is not currently reachable. Nevertheless, WARN_ON() on any fallible call is the wrong pattern at EL2. Capture the return value and propagate it. The unmap() and host-side rollback are kept as defensive guards for the currently unreachable failure path. The rollback's WARN_ON(__host_set_page_state_range()) asserts an impossible state: the host leaf PTE was just written by host_stage2_set_owner_metadata_locked(), so the reverse idmap rewrite cannot require new page-table allocation from host_s2_pool. This is the correct use of WARN_ON at EL2 =E2=80=94 an impossible-state assertion, not a reachable error being ignored. Fixes: 246c976c370d ("KVM: arm64: Implement the MEM_UNSHARE hypercall for p= rotected VMs") Signed-off-by: Fuad Tabba --- arch/arm64/kvm/hyp/nvhe/mem_protect.c | 37 ++++++++++++++++++--------- 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/arch/arm64/kvm/hyp/nvhe/mem_protect.c b/arch/arm64/kvm/hyp/nvh= e/mem_protect.c index 6fb546af699f..12f3ea7a2d75 100644 --- a/arch/arm64/kvm/hyp/nvhe/mem_protect.c +++ b/arch/arm64/kvm/hyp/nvhe/mem_protect.c @@ -984,14 +984,10 @@ int __pkvm_guest_share_host(struct pkvm_hyp_vcpu *vcp= u, u64 gfn) &vcpu->vcpu.arch.pkvm_memcache, 0); if (ret) { /* - * Stage-2 map can fail mid-walk (e.g. -ENOMEM from the - * memcache), leaving partial leaf entries in the guest - * stage-2 transitioned to PKVM_PAGE_SHARED_OWNED. Tear - * them down so the host does not see a partially-shared - * mapping it has not yet acknowledged via the host - * stage-2 update below. No host bookkeeping needs - * unwinding here: the only mutation prior to the failed - * map is the (now-discarded) guest stage-2 update itself. + * Defensive: get_valid_guest_pte() guarantees a last-level + * leaf PTE already exists, so stage-2 map() cannot currently + * fail here. The unmap() restores the IPA to a clean state as + * a guard should the precondition ever change. */ kvm_pgtable_stage2_unmap(&vm->pgt, ipa, PAGE_SIZE); goto unlock; @@ -1024,13 +1020,30 @@ int __pkvm_guest_unshare_host(struct pkvm_hyp_vcpu = *vcpu, u64 gfn) if (__host_check_page_state_range(phys, PAGE_SIZE, PKVM_PAGE_SHARED_BORRO= WED)) goto unlock; =20 - ret =3D 0; meta =3D host_stage2_encode_gfn_meta(vm, gfn); WARN_ON(host_stage2_set_owner_metadata_locked(phys, PAGE_SIZE, PKVM_ID_GUEST, meta)); - WARN_ON(kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys, - pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_OWNED), - &vcpu->vcpu.arch.pkvm_memcache, 0)); + ret =3D kvm_pgtable_stage2_map(&vm->pgt, ipa, PAGE_SIZE, phys, + pkvm_mkstate(KVM_PGTABLE_PROT_RWX, PKVM_PAGE_OWNED), + &vcpu->vcpu.arch.pkvm_memcache, 0); + if (ret) { + /* + * Defensive: get_valid_guest_pte() guarantees a last-level + * leaf PTE already exists, so stage-2 map() cannot currently + * fail here. The unmap() and host-side rollback below are + * kept as guards should the precondition ever change. + */ + kvm_pgtable_stage2_unmap(&vm->pgt, ipa, PAGE_SIZE); + + /* + * Roll back the host stage-2 mutation above: the host leaf + * PTE was just written by host_stage2_set_owner_metadata_locked(), + * so __host_set_page_state_range() rewrites it in-place + * without needing fresh page-table pages from host_s2_pool. + */ + WARN_ON(__host_set_page_state_range(phys, PAGE_SIZE, + PKVM_PAGE_SHARED_BORROWED)); + } unlock: guest_unlock_component(vm); host_unlock_component(); --=20 2.54.0.545.g6539524ca2-goog