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=-11.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 25D1CC07E95 for ; Tue, 13 Jul 2021 15:53:44 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id CEF43611AB for ; Tue, 13 Jul 2021 15:53:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CEF43611AB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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=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=9NXD00n+GIxfshqsQJaGvCuLlfsslup7H+C3MA1iWYE=; b=es8H3avXt/0N+a FzzOLhsnWISiLwlmK/FdGECZ6BkB+lc/MFscq/wLaGDoWB3Z4XRN2qm8AuBlhHYCOIn57afvcL+nj 0ATqeVcBkSzR7Lpz3SZq3yM1iRp1lfAQM4gdeifeKQMad18sw2XsuCh5KckvyxWXfCI0LUVCkbYvy dekq+iyziYoR6bnb1gK0a0c2zrr1FS8WjfkZYk2lnm8d9+3wfDA8ZFMoOh3q9f37IHJJN5nl8aRgA nlrzmUym1f2PwHaRGxRAusU+0zeiReEDplXT+ml9pYdk2kpIyaBgPJq4OXTP0H6DWDz0uWV3jUGAl A0+Vc1e9za+El8E9f0yQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1m3Khi-00AruX-Nc; Tue, 13 Jul 2021 15:52:14 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1m3Khf-00Artn-29 for linux-arm-kernel@lists.infradead.org; Tue, 13 Jul 2021 15:52:12 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id E05DC611AB; Tue, 13 Jul 2021 15:52:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1626191530; bh=R4t55Q8JlVfODQuEB737+QvELXXtuqYe/76zqWeTJ70=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=W/J6qYRQG8hsiU+PUeRXvkXTCribGhHfoTO4lVL8IVb+pVWkpUp1CNk9xEyJwsqJT JSArLyqtLKjJwiI/TnZXo9aNvg0fBTqNABVI9GQaFyv+2HuEzqG8Q5dLq2tx7JjAMY tt2O17PCOs1lj39P9753M8s/0H2+aIl/fnchat/N4hxt2l5fsUjLY3U77S6DJKesay k2/g4IEfH9VyG0ob3nPWr4LZpKh5I0MKmXnZL+Sn3ad9PNvEeHIYxtxiDdcnKZj1jb z2UQ6/HbLhd3XL47isC6rBOC7isFlzRGPerGzFyr3Lo2HQxd2LdYJmtXbc5u+RTMjO RJOK2Hx6msg+Q== Date: Tue, 13 Jul 2021 16:52:04 +0100 From: Will Deacon To: Peter Collingbourne Cc: Catalin Marinas , Vincenzo Frascino , Andrey Konovalov , Evgenii Stepanov , Szabolcs Nagy , Tejas Belagod , linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v3] arm64: mte: optimize GCR_EL1 modification on kernel entry/exit Message-ID: <20210713155204.GA30184@willie-the-truck> References: <20210709014941.2014210-1-pcc@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210709014941.2014210-1-pcc@google.com> 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-20210713_085211_181941_F6045C6D X-CRM114-Status: GOOD ( 25.98 ) 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, Jul 08, 2021 at 06:49:41PM -0700, Peter Collingbourne wrote: > Accessing GCR_EL1 and issuing an ISB can be expensive on some > microarchitectures. Although we must write to GCR_EL1, we can > restructure the code to avoid reading from it because the new value > can be derived entirely from the exclusion mask, which is already in > a GPR. Do so. > > Furthermore, although an ISB is required in order to make this system > register update effective, and the same is true for PAC-related updates > to SCTLR_EL1 or APIAKey{Hi,Lo}_EL1, we issue two ISBs on machines > that support both features while we only need to issue one. To avoid > the unnecessary additional ISB, remove the ISBs from the PAC and > MTE-specific alternative blocks and add an ISB in a separate block > that is activated only if either feature is supported. Sorry to be a pain, but can you split this into two patches, please? I think you're making two distinct changes, and it would be easier to review and discuss them separately (it would also be interesting to know the relative performance improvement you get from them). > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c > index efed2830d141..740e09ade2ea 100644 > --- a/arch/arm64/kernel/cpufeature.c > +++ b/arch/arm64/kernel/cpufeature.c > @@ -1717,6 +1717,20 @@ static bool has_generic_auth(const struct arm64_cpu_capabilities *entry, > } > #endif /* CONFIG_ARM64_PTR_AUTH */ > > +static bool has_address_auth_or_mte(const struct arm64_cpu_capabilities *entry, > + int scope) > +{ > +#ifdef CONFIG_ARM64_PTR_AUTH > + if (has_address_auth_metacap(entry, scope)) > + return true; > +#endif > +#ifdef CONFIG_ARM64_MTE > + if (__system_matches_cap(ARM64_MTE)) > + return true; > +#endif > + return false; > +} > + > #ifdef CONFIG_ARM64_E0PD > static void cpu_enable_e0pd(struct arm64_cpu_capabilities const *cap) > { > @@ -2218,6 +2232,11 @@ static const struct arm64_cpu_capabilities arm64_features[] = { > .matches = has_cpuid_feature, > .min_field_value = 1, > }, > + { > + .capability = ARM64_HAS_ADDRESS_AUTH_OR_MTE, > + .type = ARM64_CPUCAP_BOOT_CPU_FEATURE, > + .matches = has_address_auth_or_mte, > + }, I'd rather avoid adding a new cap for this, as these features are entirely unrelated in the architecture and if we end up piling more combinations of features in here in the future then I fear it will become quite unwieldy. Instead, how about we just use a conditional branch alongside the existing capabilities? E.g. alternative_if ARM64_MTE isb b 1f alternative_else_nop_endif alternative_if ARM64_HAS_ADDRESS_AUTH isb alternative_else_nop_endif 1: ? Failing that, maybe you could use alternative_cb to avoid the new capability, but I'm not sure it's worth it. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel