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

[Mark Brown]

On Wed, Feb 04, 2026 at 03:54:05PM +0000, Peter Maydell wrote:
> On Mon, 2 Feb 2026 at 18:01, Mark Brown <broonie at kernel.org> wrote:

> > 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.)

Exactly what you described there, leading to the situation where if we
just set hwcaps based purely on the value of ID_AA64ZFR0_EL1 on a SME
only system we end up setting SVE only hwcaps and potentially confusing
userspace into thinking SVE is supported on a SME only system.  This was
the case for a long time but was fixed by Marc in 064737920bdb ("arm64:
Filter out SVE hwcaps when FEAT_SVE isn't implemented").
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20260204/0e093a40/attachment.sig>