From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 71A3A35E1D3; Tue, 14 Jul 2026 14:12:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784038344; cv=none; b=UejDA82EXau0Cw43KocA3ESe4KaVdJKDXkKsNVr6iQY8Go5TRRNSN1BhgViqfVn2cFaqlwSlUHV2WXM4Uniz+PsZrS2pl0saQcR5ehNUhqY7v9o4yNTxYC3x/EvD5oCWawfc1N5XWAIU5K3xzrO5cyICHYHRxdtTG9jhziT1MDY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784038344; c=relaxed/simple; bh=aLyPVzhCOpxEYvqb+mdtt5+ZdV9EvzfsF8uBakUUHW0=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=GDS5cpX2Wm2GjP+98ZVi8FbhZtDirEA1sYGhvZcUi64Z8l6yVkRs9CPK4j3MS36u7tPVG1EAHj5sWx2tmIZF83cB9t1hDQ15LMbkNoVafqqXfsAlJjAkIT5547rCvFI5yEFwNqZgO3rg55Um2Hm7yOdg7AImpmLXxa36dwzsJC0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=S7a3NiNh; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="S7a3NiNh" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D6971F000E9; Tue, 14 Jul 2026 14:12:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784038343; bh=hNRmwdjWvBOciKRs4ryAEgtsV7SkVI3x2lqu3ub7VWM=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=S7a3NiNhkCoB5S81qVFcNTN/3CfyXyUFG+Y2GyW1fh5N4yj3cXWTg84JmLK/ICLvq 0l+aatEwDgQEQ9YVZiLSKh36PgXMwY166nXSgiVjaf4bC8TgtyauZ3/rHHvTva54kV WCVjMoQBk2LpdhHxi59dDlnzEvjtg/U3DZ4Ud94818y9mP15bKhG6NGiL/wKiiB1sP tocpVjVeZgb+7UaXKp04ZI0NHGS6uzNrluB0LkEvBGkuO4mD3q+wQ4zkn6NIznfx5V r9Kq2L906KfmdsBfqvPMZmZoy3S/WECb9PI+wHQ0beAEwndFHnoM6Nk35CSqXrMrAu YREP8onuq7KdQ== 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 1wjdrx-00000004w2v-0hGd; Tue, 14 Jul 2026 14:12:21 +0000 Date: Tue, 14 Jul 2026 15:12:20 +0100 Message-ID: <86se5loe2j.wl-maz@kernel.org> From: Marc Zyngier To: sashiko-reviews@lists.linux.dev Cc: kvmarm@lists.linux.dev, "Oliver Upton" , kvm@vger.kernel.org Subject: Re: [PATCH v2 09/28] KVM: arm64: Relax CPTR_EL2 handling when FEAT_NV2p1 is present In-Reply-To: <20260714101236.905141F000E9@smtp.kernel.org> References: <20260714091641.1970822-1-maz@kernel.org> <20260714091641.1970822-10-maz@kernel.org> <20260714101236.905141F000E9@smtp.kernel.org> 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: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: 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: sashiko-reviews@lists.linux.dev, kvmarm@lists.linux.dev, oupton@kernel.org, kvm@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false On Tue, 14 Jul 2026 11:12:36 +0100, sashiko-bot@kernel.org wrote: > > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: > - [High] Nested trap configuration for CPTR_EL2 is evaluated using a stale memory backing store under FEAT_NV2P1, breaking nested virtualization isolation. > -- > > --- Patch [9]: [PATCH v2 09/28] KVM: arm64: Relax CPTR_EL2 handling when FEAT_NV2p1 is present --- > commit c67129a02beeb5d291611085a5d2f889ac9d97e8 > Author: Marc Zyngier > > KVM: arm64: Relax CPTR_EL2 handling when FEAT_NV2p1 is present > > This patch relaxes the handling of CPTR_EL2 accesses via CPACR_EL1 when > FEAT_NV2P1 is present, stopping the trap of CPACR_EL1. It modifies the > read path to use the hardware SYS_CPACR_EL1 register instead of the > memory backing store for CPTR_EL2. > > [ ... ] > > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > > index 6b47d936efb32..1dfc1f88bec82 100644 > > --- a/arch/arm64/kvm/sys_regs.c > > +++ b/arch/arm64/kvm/sys_regs.c > > @@ -326,7 +326,10 @@ u64 vcpu_read_sys_reg(const struct kvm_vcpu *vcpu, enum vcpu_sysreg reg) > > val |= __vcpu_sys_reg(vcpu, reg) & ~CNTKCTL_VALID_BITS; > > return val; > > case CPTR_EL2: > > - return __vcpu_sys_reg(vcpu, reg); > > + if (cpus_have_final_cap(ARM64_HAS_NV2P1)) > > + return read_sysreg_el1(SYS_CPACR); > > + else > > + return __vcpu_sys_reg(vcpu, reg); > > [Severity: High] > Since this changes CPTR_EL2 to be read directly from the hardware register > SYS_CPACR under FEAT_NV2P1 (as the memory backing store can be stale without > trapping), will direct readers of the backing store now read stale values? > > For example, in arch/arm64/kvm/emulate-nested.c:get_behaviour(): > > val = __vcpu_sys_reg(vcpu, tb->index); get_behaviour() is only called when a trap from L2 needs to be routed to L1. Therefore, the L1 registers cannot be resident at this point, and looking for them in memory is the right thing to do. > > And in arch/arm64/kvm/emulate-nested.c:check_cptr_tta(): > > u64 val = __vcpu_sys_reg(vcpu, CPTR_EL2); > > Because the L1 guest writes to CPACR_EL1 natively without trapping, the > backing store is not synchronously updated. If an L2 guest traps to host > KVM, wouldn't these functions evaluate trap configurations using the stale > memory backing store, potentially bypassing the L1 hypervisor's trap > configurations? If running an L2, L1's view of CPTR_EL2 (which it accessed as CPACR_EL1) cannot be resident. Where would L2's accesses to CPACR_EL1 go otherwise? You don't understand NV. M. -- Without deviation from the norm, progress is not possible.