From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC PATCH v3 3/3] arm64/kernel: enable A53 erratum #8434319 handling at runtime
Date: Mon, 5 Mar 2018 17:40:00 +0000 [thread overview]
Message-ID: <20180305173959.GB13385@arm.com> (raw)
In-Reply-To: <CAKv+Gu-qZR57jaLUjhJFkP2u=XzEN7ewX+GsrKbPbbONwvxBww@mail.gmail.com>
On Mon, Mar 05, 2018 at 05:29:26PM +0000, Ard Biesheuvel wrote:
> On 5 March 2018 at 17:22, Will Deacon <will.deacon@arm•com> wrote:
> > On Wed, Feb 14, 2018 at 11:36:45AM +0000, Ard Biesheuvel wrote:
> >> Omit patching of ADRP instruction at module load time if the current
> >> CPUs are not susceptible to the erratum.
> >>
> >> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro•org>
> >> ---
> >> Open question: how should we handle big.LITTLE configurations where affected
> >> Cortex-A53s may appear late.
> >
> > We should fail to bring them online. I think the infrastructure already
> > exists for this and we used it for other errata already.
> >
>
> I think that is what it does currently. The question is whether that
> should be considered a regression or not.
This can only happen with maxcpus=, right? I wouldn't be too worried about
it in that case.
>
> >> diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
> >> index bb263820de13..39134c46bb13 100644
> >> --- a/arch/arm64/include/asm/cpucaps.h
> >> +++ b/arch/arm64/include/asm/cpucaps.h
> >> @@ -45,7 +45,8 @@
> >> #define ARM64_HARDEN_BRANCH_PREDICTOR 24
> >> #define ARM64_HARDEN_BP_POST_GUEST_EXIT 25
> >> #define ARM64_HAS_RAS_EXTN 26
> >> +#define ARM64_WORKAROUND_843419 27
> >>
> >> -#define ARM64_NCAPS 27
> >> +#define ARM64_NCAPS 28
> >>
> >> #endif /* __ASM_CPUCAPS_H */
> >> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> >> index 07823595b7f0..c065d5649b1b 100644
> >> --- a/arch/arm64/kernel/cpu_errata.c
> >> +++ b/arch/arm64/kernel/cpu_errata.c
> >> @@ -228,6 +228,23 @@ static int qcom_enable_link_stack_sanitization(void *data)
> >> }
> >> #endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
> >>
> >> +static bool __maybe_unused
> >> +needs_erratum_843419_workaround(const struct arm64_cpu_capabilities *entry,
> >> + int scope)
> >> +{
> >> + u32 cpuid = read_cpuid_id();
> >> +
> >> + WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());
> >> +
> >> + if ((cpuid & MIDR_CPU_MODEL_MASK) != MIDR_CORTEX_A53)
> >> + return false;
> >> + else if ((cpuid & (MIDR_REVISION_MASK | MIDR_VARIANT_MASK)) == 0x4)
> >> + /* erratum was fixed in some versions of r0p4 */
> >> + return !(read_cpuid(REVIDR_EL1) & BIT(8));
> >
> > The rXpY information is in the MIDR, so this is checking for something else
> > afaict.
> >
>
> No, it checks the REVIDR of r0p4 parts, of which bit 8 tells us if
> this specific erratum has been fixed.
/me checks errata notice.
Ok, fair enough! Given that it looks like this mechanism is used for other
errata too, it would make sense to support it in the arm64_cpu_capabilities
structure alongside the midr stuff.
Will
next prev parent reply other threads:[~2018-03-05 17:40 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-14 11:36 [RFC PATCH v3 0/3] arm64/kernel: get rid of GCC large model code Ard Biesheuvel
2018-02-14 11:36 ` [RFC PATCH v3 1/3] arm64/kernel: kaslr: reduce module randomization range to 4 GB Ard Biesheuvel
2018-02-23 17:00 ` Mark Rutland
2018-02-23 17:07 ` Ard Biesheuvel
2018-03-05 12:22 ` Ard Biesheuvel
2018-02-14 11:36 ` [RFC PATCH v3 2/3] arm64/kernel: don't ban ADRP to work around Cortex-A53 erratum #843419 Ard Biesheuvel
2018-02-23 17:15 ` Mark Rutland
2018-02-23 17:17 ` Ard Biesheuvel
2018-02-23 17:25 ` Mark Rutland
2018-02-24 17:54 ` Ard Biesheuvel
2018-02-26 10:53 ` Mark Rutland
2018-03-05 17:18 ` Will Deacon
2018-03-05 17:26 ` Ard Biesheuvel
2018-03-05 17:34 ` Will Deacon
2018-03-05 17:41 ` Ard Biesheuvel
2018-03-05 17:42 ` Will Deacon
2018-02-14 11:36 ` [RFC PATCH v3 3/3] arm64/kernel: enable A53 erratum #8434319 handling at runtime Ard Biesheuvel
2018-02-23 17:23 ` Mark Rutland
2018-03-05 17:22 ` Will Deacon
2018-03-05 17:29 ` Ard Biesheuvel
2018-03-05 17:40 ` Will Deacon [this message]
2018-03-05 18:01 ` Ard Biesheuvel
2018-03-06 15:25 ` Will Deacon
2018-03-05 17:40 ` [RFC PATCH v3 0/3] arm64/kernel: get rid of GCC large model code Will Deacon
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=20180305173959.GB13385@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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