From: Ard Biesheuvel <ardb@kernel.org>

The Cortex-A53 r0p4 revision that QEMU emulates is affected by a CatA
erratum #843419 (i.e., the most severe), which requires workarounds in
the toolchain as well as the OS.

Since the emulation is obviously not affected in the same way, we can
indicate this via REVIDR bit #8, which on r0p4 has the meaning that no
workarounds for erratum #843419 are needed.

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 target/arm/cpu64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index 8e30a7993e..0f7a44a28f 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -663,7 +663,7 @@ static void aarch64_a53_initfn(Object *obj)
     set_feature(&cpu->env, ARM_FEATURE_PMU);
     cpu->kvm_target = QEMU_KVM_ARM_TARGET_CORTEX_A53;
     cpu->midr = 0x410fd034;
-    cpu->revidr = 0x00000000;
+    cpu->revidr = 0x00000100;
     cpu->reset_fpsid = 0x41034070;
     cpu->isar.mvfr0 = 0x10110222;
     cpu->isar.mvfr1 = 0x12111111;
-- 
2.43.0.687.g38aa6559b0-goog

On Thu, 15 Feb 2024 at 16:02, Ard Biesheuvel <ardb+git@google.com> wrote:
>
> From: Ard Biesheuvel <ardb@kernel.org>
>
> The Cortex-A53 r0p4 revision that QEMU emulates is affected by a CatA
> erratum #843419 (i.e., the most severe), which requires workarounds in
> the toolchain as well as the OS.
>
> Since the emulation is obviously not affected in the same way, we can
> indicate this via REVIDR bit #8, which on r0p4 has the meaning that no
> workarounds for erratum #843419 are needed.
>
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>



Applied to target-arm.next, thanks.

-- PMM

On 2/15/24 06:02, Ard Biesheuvel wrote:
> From: Ard Biesheuvel <ardb@kernel.org>
> 
> The Cortex-A53 r0p4 revision that QEMU emulates is affected by a CatA
> erratum #843419 (i.e., the most severe), which requires workarounds in
> the toolchain as well as the OS.
> 
> Since the emulation is obviously not affected in the same way, we can
> indicate this via REVIDR bit #8, which on r0p4 has the meaning that no
> workarounds for erratum #843419 are needed.
> 
> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> ---
>   target/arm/cpu64.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index 8e30a7993e..0f7a44a28f 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -663,7 +663,7 @@ static void aarch64_a53_initfn(Object *obj)
>       set_feature(&cpu->env, ARM_FEATURE_PMU);
>       cpu->kvm_target = QEMU_KVM_ARM_TARGET_CORTEX_A53;
>       cpu->midr = 0x410fd034;
> -    cpu->revidr = 0x00000000;
> +    cpu->revidr = 0x00000100;

Is it worth indicating all three errata fixes (bits 7-9)?

Anyway,
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~

On Thu, 15 Feb 2024 at 21:47, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 2/15/24 06:02, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@kernel.org>
> >
> > The Cortex-A53 r0p4 revision that QEMU emulates is affected by a CatA
> > erratum #843419 (i.e., the most severe), which requires workarounds in
> > the toolchain as well as the OS.
> >
> > Since the emulation is obviously not affected in the same way, we can
> > indicate this via REVIDR bit #8, which on r0p4 has the meaning that no
> > workarounds for erratum #843419 are needed.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> >   target/arm/cpu64.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> > index 8e30a7993e..0f7a44a28f 100644
> > --- a/target/arm/cpu64.c
> > +++ b/target/arm/cpu64.c
> > @@ -663,7 +663,7 @@ static void aarch64_a53_initfn(Object *obj)
> >       set_feature(&cpu->env, ARM_FEATURE_PMU);
> >       cpu->kvm_target = QEMU_KVM_ARM_TARGET_CORTEX_A53;
> >       cpu->midr = 0x410fd034;
> > -    cpu->revidr = 0x00000000;
> > +    cpu->revidr = 0x00000100;
>
> Is it worth indicating all three errata fixes (bits 7-9)?
>

835769 has a build time workaround in the linker which I don't think
we even bother to enable in the kernel build. It is definitely not
something the OS needs to worry about at runtime, so I don't think it
matters.

The other one is a performance related CatC without a workaround, so
that one can be ignored as well.

OTOH, our emulation is affected by neither so setting the REVIDR bits
for them makes sense. But there is simply no software that I am aware
of that will behave differently as a result (as opposed to the one for
843419, which is read by the Linux kernel and triggers workaround
logic in the module loader)

> Anyway,
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
>

Thanks.