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 D1CB0320F for ; Wed, 4 Jun 2025 18:58:15 +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=1749063499; cv=none; b=WicGAnIPoCogkQoYb+DLtBYTi5nGuPousG1IsDxBydtYlUJNoI6DqOFtYm1UWfY32bqhq+6bhuHwI+HX7PfuO6fmRvACZ1kmxF+vpAHjfkQaa1gTeaRei1AyVb+8AIJbmWJSpcpbe5rOufTm0tWYnBASuBRTlduC5SXpdfWGUHE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1749063499; c=relaxed/simple; bh=eUnmTJwiF/5X4d8p1DufRVVsKor+rR4PUXMhQywg6OI=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=GjtdiC+75jwX6R0S9CTrDq26yGn8JzM4kjUvUrfHBt+i2Lq60XSs/1nf8ed1IA0STsShFKn8Ucq7F2Flqpo7BdVF8VdbYzg7ohhs7BdsyGk6AmCKroR/qua7HXZyQn4sJttD2FD/8WjUFVCa9yd9Nb3RsUoodNXHulbg9XhiV/E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IK9enBNF; 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="IK9enBNF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E36AC4CEED; Wed, 4 Jun 2025 18:58:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749063495; bh=eUnmTJwiF/5X4d8p1DufRVVsKor+rR4PUXMhQywg6OI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=IK9enBNF87alFNn+k+dH4Ax2tmd5j9/nWa8YVhDOQKJM1NmyrbQQJ9OlhNouN6QGY WdepCy5d5U05M3vbM4Za5h/leU36RfxGsHcD/NawkhyNvC2bIbTbmUUSiXuu7AT/Ev Pdo6Nreghv07ab46M3yH0g2vDntiH8LBJw0ZF5LIRlmc5HcRzichInMltm2BZJCfCg h1c5cWG9IXGuFr9nbSzyKGJJT7+WH5C7l8NBhOMpHPMPeXRA4GOx3fpoB8mCIwQg5m ess8EGmU+teEQauGUQbcHkw6vkPtqetSnlj/epkae/agWo9DaxuWVDKBM4NntMLA0W cs10mJcC8QCVQ== 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 1uMtJU-003Lvi-PG; Wed, 04 Jun 2025 19:58:13 +0100 Date: Wed, 04 Jun 2025 19:58:11 +0100 Message-ID: <877c1re3lo.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: References: <20250603070824.1192795-1-maz@kernel.org> <2264D21F-C28B-4523-9132-A53EB8ABFCF0@oracle.com> <87bjr3edsr.wl-maz@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=UTF-8 Content-Transfer-Encoding: quoted-printable 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 16:53:01 +0100, Miguel Luis wrote: >=20 >=20 >=20 > > On 4 Jun 2025, at 15:17, Marc Zyngier wrote: > >=20 > > On Wed, 04 Jun 2025 11:47:57 +0100, > > Miguel Luis wrote: > >>=20 > >> Hi Marc, > >>=20 > >>> On 3 Jun 2025, at 07:08, Marc Zyngier wrote: > >>>=20 > >>> 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. > >>>=20 > >>> 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. > >>>=20 > >>> 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. > >>>=20 > >>> 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=20 > >>> legacy accessor to be converted to rvalue-only. > >>>=20 > >>> 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. > >>>=20 > >>=20 > >> For the series: > >> Reviewed-by: Miguel Luis > >=20 > > Thanks. > >=20 > >>=20 > >> nit: the rmw accessor implies an implicit assignment which could be sp= ecified > >> within its macro instead but it's fine by me. > >=20 > > 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. > >=20 > > Does the following change address your concern? If not, please clearly > > point out what you're after. >=20 > I believe this should give a clearer idea while avoids repeating the assi= gnment everywhere > the accessor is used. Just replace =E2=80=98&=3D=E2=80=98 and =E2=80=98|= =3D=E2=80=98 by =E2=80=98&=E2=80=99 and =E2=80=98|=E2=80=99. I have the opposite view. I think the '=3D' sign conveys an important meaning, and hiding it makes things less obvious. If I had lost common sense and was writing C++ , I would have simply overloaded the various operators, retaining the existing syntax. This macro does the hard job of applying the RESx masks, but the operator is what is semantically significant. Thanks, M. --=20 Jazz isn't dead. It just smells funny.