Re: gdb support for SME-without-SVE ?

[Peter Maydell via Gdb <gdb@sourceware.org>]

On Fri, 30 Jan 2026 at 19:01, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Fri, 30 Jan 2026 at 18:59, Thiago Jung Bauermann
> <thiago.bauermann@linaro.org> wrote:
> > I was able to enable SME2p1 by adding these options:
> >
> >     -C cluster0.sve.sme2_version : 1
> >     -C cluster1.sve.sme2_version : 1
> >
> > Now my features list shows sme2p1:
> >
> > Features        : fp asimd evtstrm crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop asimddp asimdfhm dit uscat ilrcpc flagm sb paca pacg gcs dcpodp flagm2 frint i8mm bf16 dgh rng bti ecv afp sme smei16i64 smef64f64 smei8i32 smef16f32 smeb16f32 smef32f32 wfxt ebf16 cssc sme2 sme2p1 smei16i32 smebi32i32 mops hbc poe lsfe
> >
> > I still get only passes in the testcase, but more tests were run now:
> >
> >                 === gdb Summary ===
> >
> > # of expected passes            286
> >
> > The sme2_version option goes all the way to SME2p3, but I didn't try
> > that one.
>
> Great -- this must be a QEMU issue.

I figured out what happens here -- if you use "-cpu max,sme=on"
a QEMU bug means this messes up the ID register value passed to the
guest (it forces the SME field in the register to 1, downgrading
it from SME2 to a weird thing that confuses the guest kernel).
If you stick to "-cpu max,sve=off" with no 'sme=on' part (relying
on the 'max' default being "SME2 is present") then you can get the
full set of 286 passes.

I'll fix the QEMU handling of the option, but in the meantime
you can use that as a workaround if you want.

thanks
-- PMM