Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Peter Maydell via Gdb <gdb@sourceware.org>
To: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Cc: Luis <luis.machado.foss@gmail.com>,
	gdb@sourceware.org,
	 Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
Subject: Re: gdb support for SME-without-SVE ?
Date: Fri, 30 Jan 2026 18:59:00 +0000	[thread overview]
Message-ID: <CAFEAcA8FXsa0oEar6--FUuBvWDtYUhki0HO-tvEnaA5e=V0twQ@mail.gmail.com> (raw)
In-Reply-To: <87ms1v7xmh.fsf@linaro.org>

On Fri, 30 Jan 2026 at 18:40, Thiago Jung Bauermann
<thiago.bauermann@linaro.org> wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > On Fri, 30 Jan 2026 at 18:18, Thiago Jung Bauermann
> > <thiago.bauermann@linaro.org> wrote:
> >> Peter Maydell <peter.maydell@linaro.org> writes:
> >> > With my updated QEMU
> >> > (which you can find in the new "sme-no-sve-2" in my gitlab repo)
> >> > that can now run the tests without making the kernel fall over.
> >> > It reports:
> >> >
> >> > # of expected passes            241
> >> > # of unexpected failures        37
> >> >
> >> > Is that the same as you see on the fast model, or does this
> >> > indicate that I still have more QEMU bugs to track down?
> >> > (Peeking into gdb.log, these failures seem to be run-on
> >> > failures from the program under test getting a SIGILL
> >> > in initialize_zt_state(), so my guess is QEMU is still not
> >> > quite right.)
> >>
> >> Indeed, there seems to be something off with QEMU.
> >> On FVP, all the tests pass:
> >>
> >>                 === gdb Summary ===
> >>
> >> # of expected passes            278
> >
> > Just to check, does your FVP have the SME2p1 feature ?
> > (Should show up as "sme2p1" in the feature list in /proc/cpuinfo
> > in the guest.)
>
> It doesn't. Here's my FVP's feature list:
>
> 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 mops hbc poe lsfe

OK. If I nobble QEMU locally to not enable SME2/SME2p1 (which
needs source changes, as there's no command line flag for it)
then I get a complete set of passes:

# of expected passes            278

So possibilities:
 * bug in your test code for the SME2p1 case
 * bug in the kernel's support for SME2p1
 * bug in QEMU's support for SME2p1

-- PMM

  reply	other threads:[~2026-01-30 18:59 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-27 11:31 Peter Maydell via Gdb
2026-01-27 14:21 ` Simon Marchi via Gdb
2026-01-27 14:47   ` Peter Maydell via Gdb
2026-01-27 14:57     ` Simon Marchi via Gdb
2026-01-27 21:23 ` Peter Maydell via Gdb
2026-01-27 21:28   ` Simon Marchi via Gdb
2026-01-28  1:07   ` Luis via Gdb
2026-01-28  4:23     ` Thiago Jung Bauermann via Gdb
2026-01-28  8:02       ` Luis via Gdb
2026-01-28 16:20       ` Peter Maydell via Gdb
2026-01-29  4:12         ` Thiago Jung Bauermann via Gdb
2026-01-29  9:10           ` Peter Maydell via Gdb
2026-01-29 11:34             ` Peter Maydell via Gdb
2026-01-30  4:28               ` Thiago Jung Bauermann via Gdb
2026-01-30  9:41                 ` Peter Maydell via Gdb
2026-01-30 12:29                 ` Peter Maydell via Gdb
2026-01-30 16:16                   ` Thiago Jung Bauermann via Gdb
2026-01-30 16:29                     ` Peter Maydell via Gdb
2026-01-30 17:06                       ` Thiago Jung Bauermann via Gdb
2026-01-30 17:17                         ` Peter Maydell via Gdb
2026-01-30 18:18                           ` Thiago Jung Bauermann via Gdb
2026-01-30 18:34                             ` Peter Maydell via Gdb
2026-01-30 18:40                               ` Thiago Jung Bauermann via Gdb
2026-01-30 18:59                                 ` Peter Maydell via Gdb [this message]
2026-01-30 18:59                                 ` Thiago Jung Bauermann via Gdb
2026-01-30 19:01                                   ` Peter Maydell via Gdb
2026-01-30 19:03                                     ` Thiago Jung Bauermann via Gdb
2026-02-02 11:01                                     ` Peter Maydell via Gdb
2026-02-02 14:06                                       ` Peter Maydell via Gdb
2026-02-02 20:43                                         ` Thiago Jung Bauermann via Gdb
2026-01-30 18:24                           ` Luis via Gdb
2026-01-27 21:29 ` Andrew Pinski via Gdb
2026-01-28  0:42 ` Luis via Gdb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFEAcA8FXsa0oEar6--FUuBvWDtYUhki0HO-tvEnaA5e=V0twQ@mail.gmail.com' \
    --to=gdb@sourceware.org \
    --cc=luis.machado.foss@gmail.com \
    --cc=manos.pitsidianakis@linaro.org \
    --cc=peter.maydell@linaro.org \
    --cc=thiago.bauermann@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox