Re: gdb support for SME-without-SVE ?

On Mon, 2 Feb 2026 at 11:01, Peter Maydell <[email protected]> wrote:
>
> On Fri, 30 Jan 2026 at 19:01, Peter Maydell <[email protected]> wrote:
> >
> > On Fri, 30 Jan 2026 at 18:59, Thiago Jung Bauermann
> > <[email protected]> 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.

...and I have now pushed an sme-no-sve-3 branch to my gitlab
QEMU repo which fixes the sme=on option handling and a few other
minor things:

https://gitlab.com/pm215/qemu/-/commits/sme-no-sve-3

-- PMM