Re: inconsistent SME2 ID register fields confuse kernel into reporting but not enabling it

On Mon, Feb 02, 2026 at 11:37:46AM +0000, Peter Maydell wrote:

I noticed that if the CPU reports an inconsistent set of SME2 related
ID register fields, this confuses the kernel into reporting it in
hwcaps and /proc/cpuinfo but not actually enabling it (so userspace
programs fall over with SIGILL).

The immediate cause of this is a QEMU bug, but Marc suggested that
you'd be interested in this report for potentially making the
kernel more robust against it.

We do have some cross checking of ID registers in the kernel, though
other than big.LITTLE consistency it's fairly limited - mainly for cases
that are architecturally valid but unhelpful (ID_AA64ZFR0_EL1 indicating
SME features on a SME only system) and those where it's part of the
implementation of an ID register override.  Mostly we assume that the
system described by the ID registers is joined up by default.

The repro case is to use a current head-of-git QEMU (I tested with
commit 587f4a1805c83a4e) and tell it '-cpu max,sme=on'. The QEMU
bug means that this gives you a CPU that generally reports SME2p1
but incorrectly has the ID_AA64PFR1_EL1.SME field set to 1, not 2.

but the code that generates /proc/cpuinfo and the hwcaps must
be looking at something else (I think ID_AA64SMFR0_EL1.SMEver) and
not cross-checking whether the earlier probing enabled SME2,
because it reports sme2 and sme2p1:

Yes, we use ID_AA64ZFR0_EL1.SVEver and ID_AA64SMFR0_EL1.SMEver for the
SVE/SME version hwcaps - this mainly falls out of the fact that we have
those for the point revisions of the features, plus the fact that we
didn't do anything that prompted a bump of ID_AA64PFR0_EL1.SVE yet so
there's only SVEver to look at for that.

I think we probably should add an explicit override here since we
support command line overriding of ID_AA64PFR1_EL1.SME so a user could
set id_aa64pfr1.sme=1 explicitly on a SME2 system for some reason which
would lead to the same invalid configuration that qemu generated here.
This gets a bit annoying since we've also got the various subfeatures
which will have their own dependencies on the core SME version, while
things that don't use any new architectural state probably aren't worth
restricting anything that interacts with ZT0 would be unimplementable on
a SME1 system and someone might reasonably check only the subfeature
capability and assume that SME2 is available based on it.