[PATCH] arm64: cpufeature: Unrestrict ID_AA64MMFR1_EL1 bit assignments

[Marc Zyngier]

On Mon, 24 Nov 2025 16:29:55 +0000,
Vladimir Zapolskiy <vladimir.zapolskiy at linaro.org> wrote:
> 
> It appears that 4 out of 8 Qualcomm SM8450 SoC cores do not generate
> an SError interrupt due to an External abort on a speculative read,
> and it is reported as a failed sanity check on boot:
> 
>     CPU features: SANITY CHECK: Unexpected variation in SYS_ID_AA64MMFR1_EL1. Boot CPU: 0x00000011212122, CPU4: 0x00000010212122
>     CPU features: SANITY CHECK: Unexpected variation in SYS_ID_AA64MMFR1_EL1. Boot CPU: 0x00000011212122, CPU5: 0x0000001021212
>     CPU features: SANITY CHECK: Unexpected variation in SYS_ID_AA64MMFR1_EL1. Boot CPU: 0x00000011212122, CPU6: 0x00000010212122
>     CPU features: SANITY CHECK: Unexpected variation in SYS_ID_AA64MMFR1_EL1. Boot CPU: 0x00000011212122, CPU7: 0x00000010212122
> 
> Due to the failed sanity check the kernel is marked as tainted in runtime:
> 
>     Tainted: [S]=CPU_OUT_OF_SPEC
> 
> Unrestrict the ID_AA64MMFR1_EL1 SpecSEI bits, since apparently it's
> a supported option at least on this heterogeneous SoC.

Supporting asymmetric configurations has always been on the basis of
having the same feature set. Just because some SoCs ignore this
requirement doesn't make it acceptable.

Tainting the kernel is the right thing to do IMO, because that's an
unexpected difference.

Additionally, making things non-strict may open a gaping hole in the
virtualisation support. All you would need to do is boot on the CPUs
that do not have SpecSEI, and bring up the CPUs that do have SpecSEI
late, *after* you have started a VM. That VM will have been told that
it cannot get a speculative SError, and yet will be able to run on
CPUs that do.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.