[PATCH] arm64: cpufeature: Unrestrict ID_AA64MMFR1_EL1 bit assignments

[PATCH] arm64: cpufeature: Unrestrict ID_AA64MMFR1_EL1 bit assignments

[Vladimir Zapolskiy]

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.

Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
 arch/arm64/kernel/cpufeature.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 5ed401ff79e3..df562b0f42af 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -472,7 +472,7 @@ static const struct arm64_ftr_bits ftr_id_aa64mmfr1[] = {
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_ETS_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_TWED_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_XNX_SHIFT, 4, 0),
-	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_HIGHER_SAFE, ID_AA64MMFR1_EL1_SpecSEI_SHIFT, 4, 0),
+	ARM64_FTR_BITS(FTR_HIDDEN, FTR_NONSTRICT, FTR_HIGHER_SAFE, ID_AA64MMFR1_EL1_SpecSEI_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_PAN_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_LO_SHIFT, 4, 0),
 	ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64MMFR1_EL1_HPDS_SHIFT, 4, 0),
-- 
2.49.0

Re: [PATCH] arm64: cpufeature: Unrestrict ID_AA64MMFR1_EL1 bit assignments

[Marc Zyngier]

On Mon, 24 Nov 2025 16:29:55 +0000,
Vladimir Zapolskiy <vladimir.zapolskiy@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.

Re: [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@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