[PATCH] arm64: cpufeature: Unrestrict ID_AA64MMFR1_EL1 bit assignments

[Vladimir Zapolskiy]

Hi Marc.

On 11/24/25 19:47, Marc Zyngier wrote:
> 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.
> 

Thank you for the detailed explanation, perhaps the unveiled problem
on Qualcomm SM8450 SoC could not be nicely resolved in the software,
and I'm convinced that leaving the kernel in the tained state is the
best option, at least I can not imagine any better workaround.

-- 
Best wishes,
Vladimir