From: Marc Zyngier <maz@kernel.org>
To: Maria Yu <quic_aiquny@quicinc.com>
Cc: <will@kernel.org>, <corbet@lwn.net>, <catalin.marinas@arm.com>,
<quic_pkondeti@quicinc.com>, <quic_kaushalk@quicinc.com>,
<quic_satyap@quicinc.com>, <quic_shashim@quicinc.com>,
<quic_songxue@quicinc.com>, <linux-doc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64: Add the arm64.nolse_atomics command line option
Date: Mon, 10 Jul 2023 08:27:00 +0100 [thread overview]
Message-ID: <875y6s8bwb.wl-maz@kernel.org> (raw)
In-Reply-To: <20230710055955.36551-1-quic_aiquny@quicinc.com>
On Mon, 10 Jul 2023 06:59:55 +0100,
Maria Yu <quic_aiquny@quicinc.com> wrote:
>
> In order to be able to disable lse_atomic even if cpu
> support it, most likely because of memory controller
> cannot deal with the lse atomic instructions, use a
> new idreg override to deal with it.
In general, the idreg overrides are *not* there to paper over HW bugs.
They are there to force the kernel to use or disable a feature for
performance reason or to guide the *enabling* of a feature, but not
because the HW is broken.
The broken status of a HW platform must also be documented so that we
know what to expect when we look at, for example, a bad case of memory
corruption (something I'd expect to see on a system that only
partially implements atomic memory operations).
>
> Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 2 ++
> arch/arm64/include/asm/cpufeature.h | 1 +
> arch/arm64/kernel/cpufeature.c | 4 +++-
> arch/arm64/kernel/idreg-override.c | 11 +++++++++++
> 4 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 85fb0fa5d091..6ad754549f1d 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -433,6 +433,8 @@
> arm64.nomops [ARM64] Unconditionally disable Memory Copy and Memory
> Set instructions support
>
> + arm64.nolse_atomic [ARM64] Unconditionally disable LSE Atomic support
> +
'nolse', or 'noatomic' should be enough. In general, the suffix should
be either derived from the FEAT_* name or the idreg field name.
> ataflop= [HW,M68k]
>
> atarimouse= [HW,MOUSE] Atari Mouse
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index 96e50227f940..9d56dea1fe62 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -916,6 +916,7 @@ extern struct arm64_ftr_override id_aa64pfr0_override;
> extern struct arm64_ftr_override id_aa64pfr1_override;
> extern struct arm64_ftr_override id_aa64zfr0_override;
> extern struct arm64_ftr_override id_aa64smfr0_override;
> +extern struct arm64_ftr_override id_aa64isar0_override;
> extern struct arm64_ftr_override id_aa64isar1_override;
> extern struct arm64_ftr_override id_aa64isar2_override;
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index f9d456fe132d..9bd766880807 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -669,6 +669,7 @@ struct arm64_ftr_override __ro_after_init id_aa64pfr0_override;
> struct arm64_ftr_override __ro_after_init id_aa64pfr1_override;
> struct arm64_ftr_override __ro_after_init id_aa64zfr0_override;
> struct arm64_ftr_override __ro_after_init id_aa64smfr0_override;
> +struct arm64_ftr_override __ro_after_init id_aa64isar0_override;
> struct arm64_ftr_override __ro_after_init id_aa64isar1_override;
> struct arm64_ftr_override __ro_after_init id_aa64isar2_override;
>
> @@ -721,7 +722,8 @@ static const struct __ftr_reg_entry {
> ARM64_FTR_REG(SYS_ID_AA64DFR1_EL1, ftr_raz),
>
> /* Op1 = 0, CRn = 0, CRm = 6 */
> - ARM64_FTR_REG(SYS_ID_AA64ISAR0_EL1, ftr_id_aa64isar0),
> + ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64ISAR0_EL1, ftr_id_aa64isar0,
> + &id_aa64isar0_override),
> ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64ISAR1_EL1, ftr_id_aa64isar1,
> &id_aa64isar1_override),
> ARM64_FTR_REG_OVERRIDE(SYS_ID_AA64ISAR2_EL1, ftr_id_aa64isar2,
> diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
> index 2fe2491b692c..af41ab4f3d94 100644
> --- a/arch/arm64/kernel/idreg-override.c
> +++ b/arch/arm64/kernel/idreg-override.c
> @@ -105,6 +105,15 @@ static const struct ftr_set_desc pfr1 __initconst = {
> },
> };
>
> +static const struct ftr_set_desc isar0 __initconst = {
> + .name = "id_aa64isar0",
> + .override = &id_aa64isar0_override,
> + .fields = {
> + FIELD("atomic", ID_AA64ISAR0_EL1_ATOMIC_SHIFT, NULL),
> + {}
> + },
> +};
> +
> static const struct ftr_set_desc isar1 __initconst = {
> .name = "id_aa64isar1",
> .override = &id_aa64isar1_override,
> @@ -163,6 +172,7 @@ static const struct ftr_set_desc * const regs[] __initconst = {
> &mmfr1,
> &pfr0,
> &pfr1,
> + &isar0,
> &isar1,
> &isar2,
> &smfr0,
> @@ -185,6 +195,7 @@ static const struct {
> { "arm64.nomops", "id_aa64isar2.mops=0" },
> { "arm64.nomte", "id_aa64pfr1.mte=0" },
> { "nokaslr", "arm64_sw.nokaslr=1" },
> + { "arm64.nolse_atomic", "id_aa64isar0.atomic=0" },
And what of 32bit?
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-07-10 7:27 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-10 5:59 [PATCH] arm64: Add the arm64.nolse_atomics command line option Maria Yu
2023-07-10 6:07 ` Randy Dunlap
2023-07-10 6:13 ` Aiqun(Maria) Yu
2023-07-10 7:27 ` Marc Zyngier [this message]
2023-07-10 8:19 ` Aiqun(Maria) Yu
2023-07-10 9:31 ` Marc Zyngier
2023-07-11 3:30 ` Aiqun(Maria) Yu
2023-07-11 6:57 ` Marc Zyngier
2023-07-11 10:12 ` Aiqun(Maria) Yu
2023-07-11 10:38 ` Marc Zyngier
2023-07-12 2:47 ` Aiqun(Maria) Yu
2023-07-12 7:29 ` Marc Zyngier
2023-07-12 8:03 ` Aiqun(Maria) Yu
2023-07-10 9:37 ` Will Deacon
2023-07-11 4:02 ` Aiqun(Maria) Yu
2023-07-11 8:22 ` Will Deacon
2023-07-11 10:15 ` Aiqun(Maria) Yu
2023-07-11 10:25 ` Will Deacon
2023-07-12 3:09 ` Aiqun(Maria) Yu
2023-07-12 7:36 ` Mark Rutland
2023-07-13 2:24 ` Aiqun(Maria) Yu
2023-07-13 11:20 ` Mark Rutland
2023-07-13 14:08 ` Aiqun(Maria) Yu
2023-07-13 19:08 ` Mark Rutland
2023-07-14 1:56 ` Aiqun(Maria) Yu
2023-07-14 1:56 ` Aiqun(Maria) Yu
2023-07-14 8:23 ` Will Deacon
2023-07-14 10:12 ` Aiqun(Maria) Yu
2023-07-14 10:12 ` Aiqun(Maria) Yu
2023-07-14 12:09 ` Will Deacon
2023-07-17 2:01 ` Aiqun(Maria) Yu
2023-07-11 10:34 ` Mark Rutland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875y6s8bwb.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_aiquny@quicinc.com \
--cc=quic_kaushalk@quicinc.com \
--cc=quic_pkondeti@quicinc.com \
--cc=quic_satyap@quicinc.com \
--cc=quic_shashim@quicinc.com \
--cc=quic_songxue@quicinc.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).