From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3C9C0C5B543 for ; Wed, 4 Jun 2025 19:00:54 +0000 (UTC) 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-Transfer-Encoding: Content-Type:MIME-Version:References:In-Reply-To:Subject:Cc:To:From: Message-ID:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=qtuzaLjmUKZZbqyxJIBOMtd2uMnDlMtZz4XqMnqYGr8=; b=YcDjwtBZ96J/QKhbKLFuKSGkVg zd2ybQn8WE4kXqq0P6QG0aph4nAwbIt8DjWWQiqI9MHxqlT0u1fMU0ZS/pGN1Ejtwg/C0jYNw45Ll n8d7jOhFb3+BLnCl7PjeZ5pyyV3qW0fWuNHuabZJlXPhQ3FF72PqvBJ4WMvDJvprW2+YOqK0M8rq2 0DPVeNZEgdHO00VB1KnWak66tSpEYLtBGd9xNhaATRxqkQH+9IOkxcegMFZd0KTVhnWD5ZI8ZvUbz q9ZggAk5DlT3bUwtGMtASteZacq6K2/+KkKAr1g7IHQKxk8fkG3yu9DamMX4NHmiNDfYPdUmd0Cfc eDkyfSJQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1uMtLe-0000000E3dh-30RD; Wed, 04 Jun 2025 19:00:26 +0000 Received: from sea.source.kernel.org ([172.234.252.31]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1uMtJX-0000000E3O5-3BC5 for linux-arm-kernel@lists.infradead.org; Wed, 04 Jun 2025 18:58:16 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 613BD4A467; Wed, 4 Jun 2025 18:58:15 +0000 (UTC) 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) 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 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250604_115815_836439_6FA9D0E9 X-CRM114-Status: GOOD ( 28.13 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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.