Message ID | 20230727-arm64-sme-fa64-hotplug-v1-1-34ae93afc05b@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:918b:0:b0:3e4:2afc:c1 with SMTP id s11csp31844vqg; Thu, 27 Jul 2023 14:56:23 -0700 (PDT) X-Google-Smtp-Source: APBJJlHF7LwA06pfxLh/GZ2I9mkUTmkNgYoRpGX2XWLnsvN8IMqBv1mm2EzXkVpTWS0Yu5Z575Hw X-Received: by 2002:a17:90b:3ece:b0:263:f9c8:9d9e with SMTP id rm14-20020a17090b3ece00b00263f9c89d9emr460066pjb.46.1690494983104; Thu, 27 Jul 2023 14:56:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1690494983; cv=none; d=google.com; s=arc-20160816; b=ZRs4io3gwulZ3OUh4mXs5AEYeRaAzOItDBxz3SLwyTLRK6HIjkWxSnSakFS0cGJyJE dfngU8DfdIHTwptYla6PK+czgm/Tnji9OfOZ/EHeT8rBF5ctleoXnZ1CUdcdMC/LLDmh U+icfu72nMMPH7cvZH5F6ObSl2D8Q9giR73h3SW72upYthMkURHIjEdP1iO7e/FTBhnd robuA6rWdiUs40+OCkxitf/6ZynpxZiFngCxqxVr8+IsVuKDSZ8DZ+g8nQScnvIU6l3p RuHFGNYGZVUMy5t99u2c9SDhSU9Fuy0Q8Ug9sPR3UyUqxtFo3sEgUQpFLzu3iCFBEt0B tjww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:message-id:content-transfer-encoding :mime-version:subject:date:from:dkim-signature; bh=KUVX80Dgm2cdcfL9uM46rMq+jcL3Ipun5XDeUWsltsY=; fh=0/vTa5h5b3EU8m1voiEvTriw1lM2c1gzkw4kvcO0zH0=; b=es+7Zj2u3t6k5vCBk8V7IIu/j/LGDffTHVEqddUkIE/ehkFq0FNjMa+rF3hKwvlsec o5PKhCmTNVopOlk9QLHjAa1KQNFH+nWdSZ9OH2fbCEUNXOWgubHn6YJKczNIhR0AAMbT DSYRdT7/I3qGr9nm6ERrnlWAQpLahB9rHjzGw0xy0avo7MicocJlkTolAYil7RUeA9OT bXhWUHJ4x2AOCnlOwW9LXoQnkTWY4yWIunmodK0AXrVAlmoiwobVZ6hjY3hrnZCRCdP/ 2fxW5ZTmbDQfXDfF8rnDaWbA4Rkyt6vkRV19SGL88gbrfQSHbCL2YC4/+546yyHZnxfA m5kQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hH3TlYxl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q62-20020a17090a1b4400b00267f3363479si1830769pjq.57.2023.07.27.14.56.09; Thu, 27 Jul 2023 14:56:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hH3TlYxl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232027AbjG0VcV (ORCPT <rfc822;kloczko.tomasz@gmail.com> + 99 others); Thu, 27 Jul 2023 17:32:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55298 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232146AbjG0VcT (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 27 Jul 2023 17:32:19 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE1BF198A for <linux-kernel@vger.kernel.org>; Thu, 27 Jul 2023 14:32:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4C2AE61F53 for <linux-kernel@vger.kernel.org>; Thu, 27 Jul 2023 21:32:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 43BDDC433C7; Thu, 27 Jul 2023 21:32:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1690493537; bh=1CRGMuJsL3YWwFkJWqZBVNQLm+e0c2Kn5gP+uFZkfnA=; h=From:Date:Subject:To:Cc:From; b=hH3TlYxlIbzFmsrhc7tqA0RbNmbOiMN1MESjZVmQCUuImg3/IaxnKpIXwLWbv7kvF 3pzqheJI7w0gYaoN2/rYXM4+qGoy+3tFxnmLV356MM0WmkoicaUMNzGFw23zTOF86f 14xXCHERBRuAXLgjIEiREtjSGHmxNCsEzOtwJCOZxPyDtxPWPArkJ94JQOLYs6eiUv AD6oxAwDC+ss933wRVeAt5HMjSpu8XdKCPMlJeSzIPcK1w/VuYyN3I7+H0Zk5b16W8 PrfMozEokSlep42J3JJd/mxElozkdhtLWaolymui3kFU9iqjbjPVpWNgx1tKzIfF1Z qmLgLuige9Xaw== From: Mark Brown <broonie@kernel.org> Date: Thu, 27 Jul 2023 22:31:44 +0100 Subject: [PATCH] arm64/fpsimd: Only provide the length to cpufeature for xCR registers MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20230727-arm64-sme-fa64-hotplug-v1-1-34ae93afc05b@kernel.org> X-B4-Tracking: v=1; b=H4sIAD/iwmQC/x2MQQqAIBAAvxJ7bqEsNPtKdJBaa6FUtCKI/p50m znMPJAoMiXoiwciXZzYuyx1WcC0GrcQ8pwdRCWaSgmFJu6yxbQTWpNh9UfYzgVrkp2WqpVWK8h xiGT5/sfD+L4fDOP8wWgAAAA= To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Dave Martin <Dave.Martin@arm.com>, Suzuki K Poulose <suzuki.poulose@arm.com> Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org> X-Mailer: b4 0.13-dev-099c9 X-Developer-Signature: v=1; a=openpgp-sha256; l=2482; i=broonie@kernel.org; h=from:subject:message-id; bh=1CRGMuJsL3YWwFkJWqZBVNQLm+e0c2Kn5gP+uFZkfnA=; b=owEBbQGS/pANAwAKASTWi3JdVIfQAcsmYgBkwuJfmjZxm299vqS0FgQ7RMOHXsS6ZOjWNxPhZZ9u dj3urxaJATMEAAEKAB0WIQSt5miqZ1cYtZ/in+ok1otyXVSH0AUCZMLiXwAKCRAk1otyXVSH0EYdB/ 9j02QwBO6pB4nb0BM8kQI73QWh+XZa0Vn8R1RubNM2+z++MgD7xbVOAMp7id+2c2D5lC4G/m/K3lLZ WArgn3zZKCKPQ91dqN9xaoBxSd4x2GHDCrWWffB/YI0tUFIFPPWSZZmegrGC1BBuCptjUQZIP6v1St J3MNHRAomp6IaW5Z8Bsf/3e17Fn8SuZ6ga4BulVwIM8me+GhD1Q2WeY7DVS4lvfSxsg+VInFEQU63q jRO+FXz0iL1xxT2xZl3qJ81lhXgcqq3fB3Kq/fzbwI0Qthh4IaJMGAtbfi/ZiljQkgrlPCCl43rD60 HkTKJUnRYyMCTkm5vWzwl5Fe2rWPGF X-Developer-Key: i=broonie@kernel.org; a=openpgp; fpr=3F2568AAC26998F9E813A1C5C3F436CA30F5D8EB X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1772612467211287200 X-GMAIL-MSGID: 1772612467211287200 |
Series |
arm64/fpsimd: Only provide the length to cpufeature for xCR registers
|
|
Commit Message
Mark Brown
July 27, 2023, 9:31 p.m. UTC
For both SVE and SME we abuse the generic register field comparison
support in the cpufeature code as part of our detection of unsupported
variations in the vector lengths available to PEs, reporting the maximum
vector lengths via ZCR_EL1.LEN and SMCR_EL1.LEN. Since these are
configuration registers rather than identification registers the
assumptions the cpufeature code makes about how unknown bitfields behave
are invalid, leading to warnings when SME features like FA64 are enabled
and we hotplug a CPU:
CPU features: SANITY CHECK: Unexpected variation in SYS_SMCR_EL1. Boot CPU: 0x0000000000000f, CPU3: 0x0000008000000f
CPU features: Unsupported CPU feature variation detected.
SVE has no controls other than the vector length so is not yet impacted
but the same issue will apply there if any are defined.
Since the only field we are interested in having the cpufeature code
handle is the length field and we use a custom read function to obtain
the value we can avoid these warnings by filtering out all other bits
when we return the register value.
Fixes: 2e0f2478ea37eb ("arm64/sve: Probe SVE capabilities and usable vector lengths")
FixeS: b42990d3bf77cc ("arm64/sme: Identify supported SME vector lengths at boot")
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/kernel/fpsimd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
---
base-commit: 6eaae198076080886b9e7d57f4ae06fa782f90ef
change-id: 20230727-arm64-sme-fa64-hotplug-1e6896746f97
Best regards,
Comments
On Thu, 27 Jul 2023 22:31:44 +0100 Mark Brown <broonie@kernel.org> wrote: > For both SVE and SME we abuse the generic register field comparison > support in the cpufeature code as part of our detection of unsupported > variations in the vector lengths available to PEs, reporting the maximum > vector lengths via ZCR_EL1.LEN and SMCR_EL1.LEN. Since these are > configuration registers rather than identification registers the > assumptions the cpufeature code makes about how unknown bitfields behave > are invalid, leading to warnings when SME features like FA64 are enabled > and we hotplug a CPU: > > CPU features: SANITY CHECK: Unexpected variation in SYS_SMCR_EL1. Boot CPU: 0x0000000000000f, CPU3: 0x0000008000000f > CPU features: Unsupported CPU feature variation detected. > > SVE has no controls other than the vector length so is not yet impacted > but the same issue will apply there if any are defined. > > Since the only field we are interested in having the cpufeature code > handle is the length field and we use a custom read function to obtain > the value we can avoid these warnings by filtering out all other bits > when we return the register value. > > Fixes: 2e0f2478ea37eb ("arm64/sve: Probe SVE capabilities and usable vector lengths") > FixeS: b42990d3bf77cc ("arm64/sme: Identify supported SME vector lengths at boot") Fixes > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > arch/arm64/kernel/fpsimd.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c > index 89d54a5242d1..c7fdeebd050c 100644 > --- a/arch/arm64/kernel/fpsimd.c > +++ b/arch/arm64/kernel/fpsimd.c > @@ -1189,11 +1189,11 @@ u64 read_zcr_features(void) > write_sysreg_s(ZCR_ELx_LEN_MASK, SYS_ZCR_EL1); > > zcr = read_sysreg_s(SYS_ZCR_EL1); > - zcr &= ~(u64)ZCR_ELx_LEN_MASK; /* find sticky 1s outside LEN field */ > + zcr &= ~(u64)ZCR_ELx_LEN_MASK; > vq_max = sve_vq_from_vl(sve_get_vl()); > zcr |= vq_max - 1; /* set LEN field to maximum effective value */ > > - return zcr; > + return SYS_FIELD_GET(ZCR_ELx, LEN, zcr); Isn't that overly complex if we only end up with the length? (if I'm reading this right) Perhaps it is more logical to build the register then pull the field out of it, but it would be simpler as something like... return sve_vq_from_vl(sve_get_vl()) - 1; > } > > void __init sve_setup(void) > @@ -1364,7 +1364,7 @@ u64 read_smcr_features(void) > vq_max = sve_vq_from_vl(sme_get_vl()); > smcr |= vq_max - 1; /* set LEN field to maximum effective value */ > > - return smcr; > + return SYS_FIELD_GET(SMCR_ELx, LEN, smcr); > } > > void __init sme_setup(void) > > --- > base-commit: 6eaae198076080886b9e7d57f4ae06fa782f90ef > change-id: 20230727-arm64-sme-fa64-hotplug-1e6896746f97 > > Best regards,
On Fri, Jul 28, 2023 at 11:27:20AM +0100, Jonathan Cameron wrote: > Mark Brown <broonie@kernel.org> wrote: > > zcr = read_sysreg_s(SYS_ZCR_EL1); > > - zcr &= ~(u64)ZCR_ELx_LEN_MASK; /* find sticky 1s outside LEN field */ > > + zcr &= ~(u64)ZCR_ELx_LEN_MASK; > > vq_max = sve_vq_from_vl(sve_get_vl()); > > zcr |= vq_max - 1; /* set LEN field to maximum effective value */ > > - return zcr; > > + return SYS_FIELD_GET(ZCR_ELx, LEN, zcr); > Isn't that overly complex if we only end up with the length? (if I'm reading this right) > Perhaps it is more logical to build the register then pull the > field out of it, but it would be simpler as something like... > return sve_vq_from_vl(sve_get_vl()) - 1; We could, yes - I did prefer to keep it clear that this is an actual if modified register value we're returning, though that could've been a comment.
On Thu, Jul 27, 2023 at 10:31:44PM +0100, Mark Brown wrote: > For both SVE and SME we abuse the generic register field comparison > support in the cpufeature code as part of our detection of unsupported > variations in the vector lengths available to PEs, reporting the maximum > vector lengths via ZCR_EL1.LEN and SMCR_EL1.LEN. Since these are > configuration registers rather than identification registers the > assumptions the cpufeature code makes about how unknown bitfields behave > are invalid, leading to warnings when SME features like FA64 are enabled > and we hotplug a CPU: > > CPU features: SANITY CHECK: Unexpected variation in SYS_SMCR_EL1. Boot CPU: 0x0000000000000f, CPU3: 0x0000008000000f > CPU features: Unsupported CPU feature variation detected. > > SVE has no controls other than the vector length so is not yet impacted > but the same issue will apply there if any are defined. > > Since the only field we are interested in having the cpufeature code > handle is the length field and we use a custom read function to obtain > the value we can avoid these warnings by filtering out all other bits > when we return the register value. > > Fixes: 2e0f2478ea37eb ("arm64/sve: Probe SVE capabilities and usable vector lengths") > FixeS: b42990d3bf77cc ("arm64/sme: Identify supported SME vector lengths at boot") > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > arch/arm64/kernel/fpsimd.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c > index 89d54a5242d1..c7fdeebd050c 100644 > --- a/arch/arm64/kernel/fpsimd.c > +++ b/arch/arm64/kernel/fpsimd.c > @@ -1189,11 +1189,11 @@ u64 read_zcr_features(void) > write_sysreg_s(ZCR_ELx_LEN_MASK, SYS_ZCR_EL1); > > zcr = read_sysreg_s(SYS_ZCR_EL1); > - zcr &= ~(u64)ZCR_ELx_LEN_MASK; /* find sticky 1s outside LEN field */ > + zcr &= ~(u64)ZCR_ELx_LEN_MASK; > vq_max = sve_vq_from_vl(sve_get_vl()); > zcr |= vq_max - 1; /* set LEN field to maximum effective value */ > > - return zcr; > + return SYS_FIELD_GET(ZCR_ELx, LEN, zcr); Hmm, now this function looks like a mixture of code which relies on the LEN field living at the bottom of the register and code which is agnostic to that. Can we update the 'zcr |= vq_max - 1' part to use something like FIELD_PREP() instead? > } > > void __init sve_setup(void) > @@ -1364,7 +1364,7 @@ u64 read_smcr_features(void) > vq_max = sve_vq_from_vl(sme_get_vl()); > smcr |= vq_max - 1; /* set LEN field to maximum effective value */ > > - return smcr; > + return SYS_FIELD_GET(SMCR_ELx, LEN, smcr); It looks like there's a similar thing here. Will
On Wed, Aug 02, 2023 at 12:21:23PM +0100, Will Deacon wrote: > On Thu, Jul 27, 2023 at 10:31:44PM +0100, Mark Brown wrote: > > - return zcr; > > + return SYS_FIELD_GET(ZCR_ELx, LEN, zcr); > Hmm, now this function looks like a mixture of code which relies on the > LEN field living at the bottom of the register and code which is agnostic > to that. > Can we update the 'zcr |= vq_max - 1' part to use something like > FIELD_PREP() instead? There was a version 2 that was sent already which goes in the opposite direction and just returns the value we would munge in without use of any FIELD_ macros: https://lore.kernel.org/r/20230731-arm64-sme-fa64-hotplug-v2-1 which also addresses your issue?
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c index 89d54a5242d1..c7fdeebd050c 100644 --- a/arch/arm64/kernel/fpsimd.c +++ b/arch/arm64/kernel/fpsimd.c @@ -1189,11 +1189,11 @@ u64 read_zcr_features(void) write_sysreg_s(ZCR_ELx_LEN_MASK, SYS_ZCR_EL1); zcr = read_sysreg_s(SYS_ZCR_EL1); - zcr &= ~(u64)ZCR_ELx_LEN_MASK; /* find sticky 1s outside LEN field */ + zcr &= ~(u64)ZCR_ELx_LEN_MASK; vq_max = sve_vq_from_vl(sve_get_vl()); zcr |= vq_max - 1; /* set LEN field to maximum effective value */ - return zcr; + return SYS_FIELD_GET(ZCR_ELx, LEN, zcr); } void __init sve_setup(void) @@ -1364,7 +1364,7 @@ u64 read_smcr_features(void) vq_max = sve_vq_from_vl(sme_get_vl()); smcr |= vq_max - 1; /* set LEN field to maximum effective value */ - return smcr; + return SYS_FIELD_GET(SMCR_ELx, LEN, smcr); } void __init sme_setup(void)