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

[Peter Maydell]

On Mon, 2 Feb 2026 at 18:01, Mark Brown <broonie at kernel.org> wrote:
>
> 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)

Hmm, what do you have in mind there? I ask because I was just
working on this for QEMU and am wondering if I misinterpreted
the Arm ARM. My reading of the definition of ID_AA64ZFR0_EL1
is that there are some features that an SME-only system
*must* report there, as well as some fields which are SVE-only
and which an SME-only system will report as 0. (I agree with
the description of this as "unhelpful" -- it would have been
clearer if SME features and feature levels were exclusively
in AA64SMFR0, so that an SME-no-SVE CPU reported ZFR0 as 0.)

thanks
-- PMM