> On 26. Jan 2026, at 09:34, Manos Pitsidianakis > <[email protected]> wrote: > > 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 > Hello,
Meanwhile the LLVM side looks un-merged: https://github.com/llvm/llvm-project/pull/165413 Maybe having a way to mask SME via “-cpu host,sme=off” and documenting it would be enough? > "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 >
