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 A0C98C25B08 for ; Sat, 20 Aug 2022 09:42:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; 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=5iLlCPPsLdL+J9psxMyXyGmcxy3PR3XcGSdamMAU9yc=; b=B1O+EpnWMXO9eW 5kIEIY3pKnqOJju9aYnho27GlXDkrixEJ7iX32jSrbmGAV/6TmL6yXqjaNji1L1PXN9YgIo8C8uD7 cNoIm3o2Ec3heMvov0CJAQz/YBSwM1aTCKvu3xbAEio0YzhXMeuFXIWgoEb1HygVgzHhDRN4Ct5Dq 2DKw29HYXpRcvHGbD4jEIadWIy7vynyajo791T+z+fR/PQe7JzaqPU4BNf1glqOnrHLH20Mnzm6ZJ lMbjgBsA9GGj7dLZJ0VO1yXU7ApNrfT94lJ8M/lq55USfBSxhRV9RLSoJhYrfgh0PJ3Uxxn9q/WKz +PtATjxpjtIgOK7/s1cw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oPKyX-006I2A-4G; Sat, 20 Aug 2022 09:41:05 +0000 Received: from ams.source.kernel.org ([145.40.68.75]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oPKyU-006Hwh-10 for linux-arm-kernel@lists.infradead.org; Sat, 20 Aug 2022 09:41:03 +0000 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 441CBB80B62; Sat, 20 Aug 2022 09:40:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A6B3AC433C1; Sat, 20 Aug 2022 09:40:55 +0000 (UTC) Date: Sat, 20 Aug 2022 10:40:51 +0100 From: Catalin Marinas To: Peter Collingbourne Cc: Evgenii Stepanov , Marc Zyngier , Will Deacon , Vincenzo Frascino , Andrey Konovalov , Mark Brown , Linux ARM , LKML Subject: Re: [PATCH] arm64: mte: move register initialization to C Message-ID: References: <20220819013526.2682765-1-pcc@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220819013526.2682765-1-pcc@google.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220820_024102_258851_47C8AEB9 X-CRM114-Status: GOOD ( 27.19 ) 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 Thu, Aug 18, 2022 at 06:35:26PM -0700, Peter Collingbourne wrote: > If FEAT_MTE2 is disabled via the arm64.nomte command line argument on a > CPU that claims to support FEAT_MTE2, the kernel will use Tagged Normal > in the MAIR. If we interpret arm64.nomte to mean that the CPU does not > in fact implement FEAT_MTE2, setting the system register like this may > lead to UNSPECIFIED behavior. I'm not convinced by this wording. There is no UNDEFINED behaviour since proc.S checks the raw ID regs. Just passing arm64.nomte currently still allows fully defined behaviour (well, unless you try to map tag storage into the linear map but changing MAIR doesn't solve that anyway). [...] > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index 907401e4fffb..3554ff869f4b 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -2030,8 +2030,47 @@ static void bti_enable(const struct arm64_cpu_capabilities *__unused) > #ifdef CONFIG_ARM64_MTE > static void cpu_enable_mte(struct arm64_cpu_capabilities const *cap) > { > + u64 rgsr; > + > sysreg_clear_set(sctlr_el1, 0, SCTLR_ELx_ATA | SCTLR_EL1_ATA0); > + > + /* > + * CnP must be enabled only after the MAIR_EL1 register has been set > + * up. Inconsistent MAIR_EL1 between CPUs sharing the same TLB may > + * lead to the wrong memory type being used for a brief window during > + * CPU power-up. > + * > + * CnP is not a boot feature so MTE gets enabled before CnP, but let's > + * make sure that is the case. > + */ > + BUG_ON(read_sysreg(ttbr0_el1) & TTBR_CNP_BIT); > + BUG_ON(read_sysreg(ttbr1_el1) & TTBR_CNP_BIT); Ah, good point. SCOPE_BOOT_CPU features are initialised before the others even for late secondary CPUs, so that should work without having to reorder the features table. > + > + /* Normal Tagged memory type at the corresponding MAIR index */ > + sysreg_clear_set( > + mair_el1, MAIR_ATTRIDX(MAIR_ATTR_MASK, MT_NORMAL_TAGGED), > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_TAGGED, MT_NORMAL_TAGGED)); Nitpick: keep 'mair_el1' on the same line with sysreg_clear_set, I think it looks slightly better if MAIR_ATTRIDX are both aligned. [...] > - /* set the TCR_EL1 bits */ > - mov_q x10, TCR_MTE_FLAGS > - orr tcr, tcr, x10 I'd keep the TCR setting under #ifdef MTE or rather the TCR_MTE_FLAGS and make them 0 if !MTE. It gives us a chance to still test a kernel configuration where TBI1 == 0. BTW, we end up setting the TCMA1 bit even when MTE is not supported. It shouldn't be a problem usually with RES0 bits which we know what they do. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel