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 X-Spam-Level: X-Spam-Status: No, score=-15.5 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91C9DC433DB for ; Mon, 29 Mar 2021 19:38:16 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B9B3661985 for ; Mon, 29 Mar 2021 19:38:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B9B3661985 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=7XhrOYQ4Jd1HDEcbIhTcCZ2shYfytQ67b+f0eDge0HQ=; b=qjSxprYMYo7jOZj7FtjY+gZJL 3NWevP7SL44nxNRddLdrAsGmB6c3vzXf7LNlK8bp2sNfHd2k4Cnn+2cNwXSKfTkBy0SVJp87mQR4e oCGT2yoZxVzK6IsXbcLvyuRZDF+SL9lxc+l6DXN3MXJGgJlskKOmE0OJojJebIyQAl+SZSrND68NV 3q0Yel7NwErZXiUBXIbmHoCSGyI1M4sDt9uIe01LEBleJs7yhb+PCF723hFS+e3ab5V9XysbECiI6 3Wna37+jEO1ZeXn+epWu1H7DIiDlEDtpJWoLgiZl1zqMTBcvdjqEgxR7sQfPWD9IBusxONYqqHqOP VcdXrsPgg==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lQxfq-001GmL-Ht; Mon, 29 Mar 2021 19:35:42 +0000 Received: from mail.kernel.org ([198.145.29.99]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lQqpJ-000dgX-Mo for linux-arm-kernel@lists.infradead.org; Mon, 29 Mar 2021 12:17:03 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 2522560235; Mon, 29 Mar 2021 12:16:55 +0000 (UTC) Date: Mon, 29 Mar 2021 13:16:53 +0100 From: Catalin Marinas To: Will Deacon Cc: Mark Brown , linux-arm-kernel@lists.infradead.org, Mark Rutland Subject: Re: [PATCH] arm64: Document requirements for fine grained traps at boot Message-ID: <20210329121653.GB6556@arm.com> References: <20210312154917.23263-1-broonie@kernel.org> <20210326115541.GC5126@arm.com> <20210329103126.GE3207@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210329103126.GE3207@willie-the-truck> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210329_131701_949030_73FE352D X-CRM114-Status: GOOD ( 28.46 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Mar 29, 2021 at 11:31:27AM +0100, Will Deacon wrote: > On Fri, Mar 26, 2021 at 11:55:41AM +0000, Catalin Marinas wrote: > > On Fri, Mar 12, 2021 at 03:49:17PM +0000, Mark Brown wrote: > > > The arm64 FEAT_FGT extension introduces a set of traps to EL2 for accesses > > > to small sets of registers and instructions from EL1 and EL0. Currently > > > Linux makes no use of this feature, explicitly document that it should > > > be disabled when entering the kernel at EL2 (as is the architectural > > > default) to help avoid surprises. > > > > > > Signed-off-by: Mark Brown > > > --- > > > Documentation/arm64/booting.rst | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst > > > index 7552dbc1cc54..1efc2d3023bb 100644 > > > --- a/Documentation/arm64/booting.rst > > > +++ b/Documentation/arm64/booting.rst > > > @@ -270,6 +270,13 @@ Before jumping into the kernel, the following conditions must be met: > > > having 0b1 set for the corresponding bit for each of the auxiliary > > > counters present. > > > > > > + For CPUs with Fine Grained Traps (FEAT_FGT) extension present: > > > + > > > + - If the kernel is entered at EL2: > > > + > > > + - HAFGRTR_EL2, HDFGWTR_EL2, HDFGRTR_EL2, HFGWTR_EL2, HFGRTR_EL2 and > > > + HFGITR_EL2 must be initialised to 0. > > > > While this requirement is correct, documenting such individual registers > > doesn't scales well. You may run a 5 year old kernel on a newer CPU and > > we can't predict which control registers have been added and what > > side-effect they have. The architecture, at least for the above > > registers, states that if warm reset to EL2, their value is 0. I think > > the EL3 firmware (which is normally up to date with the CPU it is > > running on) should follow the ARM ARM reset values. There are probably > > EL1 registers with similar requirements (I haven't checked). > > One thing I don't understand about the registers listed here is that we're > requiring firmware to initialise them when the kernel is entered at EL2. But > they're *_EL2 registers, so why can't the kernel initialise them itself? The > fewer dependencies on firmware, the better. W.r.t. these specific registers, you are right, we'd better initialise them in the kernel rather than documenting. But in the general case, there may be new registers an old kernel is not aware of. Here we expect at least the EL3 firmware to be up to date with the CPU it is running on, hence a broad statement that such registers need to be initialised (unless we have one already). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel