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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DD54DCDB47E for ; Wed, 18 Oct 2023 12:40:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230486AbjJRMk5 (ORCPT ); Wed, 18 Oct 2023 08:40:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231267AbjJRMks (ORCPT ); Wed, 18 Oct 2023 08:40:48 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4E3041AB for ; Wed, 18 Oct 2023 05:40:41 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BD5D8C433CA; Wed, 18 Oct 2023 12:40:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697632840; bh=ANCj0Q2OJ1qzkkQO+Sp4XFTRcw4ECnG/L7DzjhbHY0o=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=PnhgzYZkM/eyLI9CA2rHMDopAQgkqfFT1BRiLbSCJoEyPGzAsGy7SKqrTfX89CTVB pE1qCMR/gLq0c7TJ/JQbahHI+QBWuRfY8qbsL8/u6wI4yYrP9eWrQ8nQyizWPxEdR/ d9GOWpiXjJrCe0mV4YeAYuzCtUbxyb1nqjxSo5yBtCEysiG4Ucjwalxw8kxwO6wqJF U3GIIf0c4YHHMmfKdrVigxcM7U+4QOKPuNK4wvPRh1rnDIU1OaKs2u2oE8tiN7y3tn HtHsjD69uI1pKgYtuVdEdJPQ4SUMvEpJUQhWr4zBmwz+6NE/0qzxjOUl5u6QII5smk hLXYiIrqfAPVw== 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.95) (envelope-from ) id 1qt5qo-005LoC-6Y; Wed, 18 Oct 2023 13:40:38 +0100 Date: Wed, 18 Oct 2023 13:40:37 +0100 Message-ID: <86r0lsm7cq.wl-maz@kernel.org> From: Marc Zyngier To: Anshuman Khandual Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Will Deacon , Oliver Upton , linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: Independently update HDFGRTR_EL2 and HDFGWTR_EL2 In-Reply-To: <20231018030007.1968317-1-anshuman.khandual@arm.com> References: <20231018030007.1968317-1-anshuman.khandual@arm.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/29.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=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, linux-kernel@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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 18 Oct 2023 04:00:07 +0100, Anshuman Khandual wrote: > > Currently PMSNEVFR_EL1 system register read, and write access EL2 traps are > disabled, via setting the same bit (i.e 62) in HDFGRTR_EL2, and HDFGWTR_EL2 > respectively. Although very similar, bit fields are not exact same in these > two EL2 trap configure registers particularly when it comes to read-only or > write-only accesses such as ready-only 'HDFGRTR_EL2.nBRBIDR' which needs to > be set while enabling BRBE on NVHE platforms. Using the exact same bit mask > fields for both these trap register risk writing into their RESERVED areas, > which is undesirable. Sorry, I don't understand at all what you are describing. You seem to imply that the read and write effects of the FGT doesn't apply the same way. But my reading of the ARM ARM is that behave completely symmetrically. Also, what is nBRBIDR doing here? It is still set to 0. What 'RESERVED' state are you talking about? > > Cc: Catalin Marinas > Cc: Will Deacon > Cc: Oliver Upton > Cc: Marc Zyngier > Cc: linux-arm-kernel@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Anshuman Khandual > --- > This applies on v6.6-rc6. > > I guess it should be okay to use 'x2' as it is in the clobbered register > list for init_el2_state() function. But please do let me know otherwise. > > arch/arm64/include/asm/el2_setup.h | 7 +++++-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/include/asm/el2_setup.h b/arch/arm64/include/asm/el2_setup.h > index 899b5c10f84c..c534afb1a30d 100644 > --- a/arch/arm64/include/asm/el2_setup.h > +++ b/arch/arm64/include/asm/el2_setup.h > @@ -206,16 +206,19 @@ > cbz x1, .Lskip_fgt_\@ > > mov x0, xzr > + mov x2, xzr > mrs x1, id_aa64dfr0_el1 > ubfx x1, x1, #ID_AA64DFR0_EL1_PMSVer_SHIFT, #4 > cmp x1, #3 > b.lt .Lset_debug_fgt_\@ > + > /* Disable PMSNEVFR_EL1 read and write traps */ > - orr x0, x0, #(1 << 62) > + orr x0, x0, #HDFGRTR_EL2_nPMSNEVFR_EL1_MASK > + orr x2, x2, #HDFGWTR_EL2_nPMSNEVFR_EL1_MASK > > .Lset_debug_fgt_\@: > msr_s SYS_HDFGRTR_EL2, x0 > - msr_s SYS_HDFGWTR_EL2, x0 > + msr_s SYS_HDFGWTR_EL2, x2 So what has changed here, aside from clobbering an extra register? The masks are the same, the initial values are the same... Is it in preparation for some other work? /me puzzled. M. -- Without deviation from the norm, progress is not possible.