On Thu, 15 Feb 2024 at 21:47, Richard Henderson <richard.hender...@linaro.org> wrote: > > On 2/15/24 06:02, Ard Biesheuvel wrote: > > From: Ard Biesheuvel <a...@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 <a...@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.hender...@linaro.org> > Thanks.
