On Thu, Jan 22, 2026 at 6:52 PM Peter Maydell <[email protected]> wrote:
>
> On Tue, 20 Jan 2026 at 10:02, Manos Pitsidianakis
> <[email protected]> wrote:
> >
> > On Tue, Jan 20, 2026 at 11:50 AM Philippe Mathieu-Daudé
> > <[email protected]> wrote:
> > >
> > > On 15/1/26 12:20, Manos Pitsidianakis wrote:
> > > > Starting from M4 cores and MacOS 15.2 SDK, HVF can virtualise FEAT_SME2.
> > > >
> > > > Reviewed-by: Mohamed Mediouni <[email protected]>
> > > > Signed-off-by: Manos Pitsidianakis <[email protected]>
> > > > ---
> > > >   target/arm/cpu.c     |  4 +++-
> > > >   target/arm/cpu64.c   | 13 ++++++++++++-
> > > >   target/arm/hvf/hvf.c | 25 +++++++++++++------------
> > > >   3 files changed, 28 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> > > > index 
> > > > caf7980b1fc5244c5c2f130e79ba869456c20c88..7f4ebfdf61217db6075495119c1b642bc2abf295
> > > >  100644
> > > > --- a/target/arm/cpu.c
> > > > +++ b/target/arm/cpu.c
> > > > @@ -1577,7 +1577,9 @@ void arm_cpu_finalize_features(ARMCPU *cpu, Error 
> > > > **errp)
> > > >            * assumes it, so if the user asked for sve=off then turn off 
> > > > SME also.
> > > >            * (KVM doesn't currently support SME at all.)
> > > >            */
> > > > -        if (cpu_isar_feature(aa64_sme, cpu) && 
> > > > !cpu_isar_feature(aa64_sve, cpu)) {
> > > > +        if (!hvf_enabled()
> > >
> > > In my experience "if(!accel)" is bug prone, maybe change to explicit "if
> > > (tcg_enabled() || kvm_enabled()"?
> >
> > Shouldn't we list all accelerators instead of just tcg/kvm then?
>
> This "turn off SME if no SVE" check is principally trying to
> avoid users hitting a bug / missing feature in TCG where
> it will assert on startup when the guest tries to write to
> SMCR_EL1 (see the backtrace in f7767ca3017's commit message),
> because we accidentally coded in assumptions that any guest
> with SME also has SVE. We turned it off for all accelerators
> because (a) at the time there weren't any others which had
> SME support and (b) we didn't do the investigation to figure
> out if any of those bogus assumptions were in code that's
> not TCG-specific. (In our defence, it was just prior to
> a QEMU release :-))
>
> To the extent that those accidental assumptions are in code
> that you can hit with HVF, we need to fix them before we
> can enable SME-no-SVE in HVF. To the extent that they're TCG
> specific, the only accelerator we really need to turn
> this off for is TCG. As the comment notes, right now
> KVM doesn't support SME so it's impossible to get here
> with SME in the feature registers.
>
> If the core code is OK for hvf to enable SME-no-SVE,
> then it should also be OK for any other accelerator
> except TCG.
>
> I don't think hvf can get to the smcr_write() function
> which is the specific failure we saw with TCG, but
> I think that it ought to be possible to end up calling
> sve_vqm1_for_el() if you use the gdbstub with hvf
> accel, get the guest into streaming SME mode (PSTATE.SM
> set), and then read the "svg" register that gdb uses to
> expose the vector granule.
>
> If giving the SME registers a good workout with the
> gdbstub interface all seems to work fine, then I think
> we can adjust this condition to be "if tcg_enabled && ...".

gdb had a disastrous workout, because it turns out it also assumes SME
must have SVE:


  (gdb) target remote localhost:1234
  Remote debugging using localhost:1234
  ../../gdb/aarch64-tdep.c:3068: internal-error:
aarch64_pseudo_register_type: bad register number 160
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  Fatal signal: Abort trap: 6

"register number 160" corresponds to pseudoregister regnum
AARCH64_SVE_V0_REGNUM. Looking at gdb/aarch64-tdep.c, it seems they
are only supported by checking against `tdep->has_sve ()` [0]

Peter: So what do we do on the QEMU side? Merge it and wait till
upstream gdb fixes it to check for bugs?

[0]: 
https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/aarch64-tdep.c;h=f1bdce453db27dffeb42f10fcd44a408f706afb2;hb=HEAD#l3116



-- 
Manos Pitsidianakis
Emulation and Virtualization Engineer at Linaro Ltd

Reply via email to