From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D9DAA1917D0 for ; Wed, 4 Jun 2025 15:18:01 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749050281; cv=none; b=k6GpzmoZmrsBpAi4/KA1Hxeu/qitunuO8y/ZTRxm3zIf19WN1gt+6C9KjWtSo7ObfAwgJ+3rtLOWBdCTlockWYXs70Hn9pYFn5r1Y3Z8OvhSCP8MjSnIHEsQmL86gCsi2im67Osc6IzzJ8wCT/R9K/NHcjMV0MVTEbwKl86OWPE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749050281; c=relaxed/simple; bh=xD1KpN3NFnTFtqrapuhJVN0NufwIbEVuXgGuab0veIQ=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=oawlcHeKQwJjHoBB12Jmx4IgEnw5l5zUTUES5l5dtuO0luMBJyF8VTwq9ueyeivDgGpONd8vF7KKgxfTOI8yvoHCG/04mHzdPfcd2EgM766RChrDTFHTTRWjYcDLwQhpu47oUYLo/GpEx00j41lJoAtlOwAz7RfrLkNrzujTz9I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ntMESso9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ntMESso9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4BD57C4CEE4; Wed, 4 Jun 2025 15:18:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749050281; bh=xD1KpN3NFnTFtqrapuhJVN0NufwIbEVuXgGuab0veIQ=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ntMESso9CJ0GSafJYxvNm8BI8FRxSZUoGrukBT7IcbxhyG0aO81pOPjvx4LXNmaV/ P3gINQh7B+msycKa+el7GWmhwwPfgPjWkNWbUpygnTaKSWC2mL99h+sFKiy+h/8tfP H50t4iHGUFfYUebwk+eibLJQBjXGZn+3NHe/BZN4GYGkesDyCWP2bIM3XVFPPVpXcp I+41Ja/AyuZtUPXNBbPcoBnwsXipXLqnkABKjWPR9dezmpZN9QclcbJhwmf56FJNnx XnIpKNYhqN+fah0Bet+BlsPyDL6E9uwvS5EnJkV1CV8Ct7t5HKiONPONFNHyRea4Yr Vp9h/eicuw8ig== Received: from [149.88.19.236] (helo=lobster-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1uMpsL-003Flv-TW; Wed, 04 Jun 2025 16:17:58 +0100 Date: Wed, 04 Jun 2025 16:17:56 +0100 Message-ID: <87bjr3edsr.wl-maz@kernel.org> From: Marc Zyngier To: Miguel Luis Cc: "kvmarm@lists.linux.dev" , "linux-arm-kernel@lists.infradead.org" , Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu Subject: Re: [PATCH v2 0/4] KVM: arm64: vcpu sysreg accessor rework In-Reply-To: <2264D21F-C28B-4523-9132-A53EB8ABFCF0@oracle.com> References: <20250603070824.1192795-1-maz@kernel.org> <2264D21F-C28B-4523-9132-A53EB8ABFCF0@oracle.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: 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: 149.88.19.236 X-SA-Exim-Rcpt-To: miguel.luis@oracle.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, joey.gouly@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, 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 On Wed, 04 Jun 2025 11:47:57 +0100, Miguel Luis wrote: > > Hi Marc, > > > On 3 Jun 2025, at 07:08, Marc Zyngier wrote: > > > > This series tries to bring some sanity to the way the RESx masks > > are applied when accessing the in-memory view of the guest's > > system registers. > > > > Currently, we have *one* accessor (__vcpu_sys_reg()) that can either > > be used as a rvalue or lvalue while that applies the RESx masks behind > > the scenes. This works fine when used as a rvalue. > > > > However, when used as a lvalue, it does the wrong thing, as it only > > sanitises the value we're about to overwrite. This is pointless work > > and potentially hides bugs. > > > > I propose that we move to a set of store-specific accessors (for > > assignments and RMW) instead of the lvalue hack, ensuring that the > > assigned value is the one that gets sanitised. This then allows the > > legacy accessor to be converted to rvalue-only. > > > > Given the level of churn this introduces, I'd like this to land very > > early in the cycle. Either before 6.16-rc2, or early in 6.17. > > > > For the series: > Reviewed-by: Miguel Luis Thanks. > > nit: the rmw accessor implies an implicit assignment which could be specified > within its macro instead but it's fine by me. I'm not sure what you mean. Looking at this macro again, the early writeback to the sysreg array is pretty unfortunate, and could be avoided. Does the following change address your concern? If not, please clearly point out what you're after. M. diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h index b4ac2f515f94..382b382d14da 100644 --- a/arch/arm64/include/asm/kvm_host.h +++ b/arch/arm64/include/asm/kvm_host.h @@ -1121,7 +1121,8 @@ u64 kvm_vcpu_apply_reg_masks(const struct kvm_vcpu *, enum vcpu_sysreg, u64); #define __vcpu_rmw_sys_reg(v, r, op, val) \ do { \ const struct kvm_cpu_context *ctxt = &(v)->arch.ctxt; \ - u64 __v = ctxt_sys_reg(ctxt, (r)) op (val); \ + u64 __v = ctxt_sys_reg(ctxt, (r)); \ + __v op (val); \ if (vcpu_has_nv((v)) && (r) >= __SANITISED_REG_START__) \ __v = kvm_vcpu_apply_reg_masks((v), (r), __v); \ \ -- Jazz isn't dead. It just smells funny.