Thread (4 messages) 4 messages, 2 authors, 2026-02-04

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

From: Peter Maydell <hidden>
Date: 2026-02-04 15:54:29

On Mon, 2 Feb 2026 at 18:01, Mark Brown [off-list ref] wrote:
On Mon, Feb 02, 2026 at 11:37:46AM +0000, Peter Maydell wrote:
quoted
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).
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help