[PATCH v2 0/6] target/arm: Allow SME-only TCG CPUs

[PATCH v2 0/6] target/arm: Allow SME-only TCG CPUs

[Peter Maydell]

These patches add support to TCG for a CPU with SME but not SVE.  We
originally prevented users from doing that in the run-up to a
release, in commit f7767ca30179 ("target/arm: Disable SME if SVE is
disabled") by forcing SME to off if SVE wasn't implemented.  This was
a simple way to avoid users hitting an assertion failure.

Changes since v1:
 * reorder patches to put the ones that affect SME+SVE
   CPUs and are worth backporting to stable first
 * change approach to fixing the smcr_write() assertion
 * fix a non-SME-aware assert in aarch64_sve_narrow_vq()
 * correct a bug in how we report the vector registers in
   the gdbstub: this fixes the problem where gdb hit an
   internal error when we emulate SME-only CPU
 * squash FEAT_SME_FA64 on SME-only CPUs

This has still not really had a great deal of testing, but
I think it's now good enough to remove the RFC tag.

thanks
-- PMM

Peter Maydell (6):
  target/arm: Account for SME in aarch64_sve_narrow_vq() assertion
  target/arm: Report correct vector width in gdbstub when SME present
  target/arm: Handle SME-only CPUs in sve_vqm1_for_el_sm()
  target/arm: Handle SME-without-SVE on change of EL
  target/arm: Squash FEAT_SME_FA64 if FEAT_SVE is not present
  target/arm: Permit configurations with SME but not SVE

 docs/system/arm/cpu-features.rst | 10 ++++++++--
 target/arm/cpu.c                 | 10 ----------
 target/arm/cpu64.c               |  5 +++++
 target/arm/gdbstub64.c           | 12 ++++++------
 target/arm/helper.c              | 14 ++++++++++----
 target/arm/internals.h           |  9 +++++++++
 6 files changed, 38 insertions(+), 22 deletions(-)

-- 
2.43.0

[PATCH v2 1/6] target/arm: Account for SME in aarch64_sve_narrow_vq() assertion

[Peter Maydell]

In aarch64_sve_narrow_vq() we assert that the new VQ is within
the maximum supported range for the CPU. We forgot to update
this to account for SME, which might have a different maximum.

Update the assert to permit any VQ which is valid for either
SVE or SME.

Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
CC stable on this one, because it might also be a problem for
a CPU with both SME and SVE but where the SVE max VL is less
than the SME max VL.
---
 target/arm/helper.c    | 2 +-
 target/arm/internals.h | 9 +++++++++
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index dce648b482..7ceab0b503 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -10076,7 +10076,7 @@ void aarch64_sve_narrow_vq(CPUARMState *env, unsigned vq)
     uint64_t pmask;
 
     assert(vq >= 1 && vq <= ARM_MAX_VQ);
-    assert(vq <= env_archcpu(env)->sve_max_vq);
+    assert(vq <= arm_max_vq(env_archcpu(env)));
 
     /* Zap the high bits of the zregs.  */
     for (i = 0; i < 32; i++) {
diff --git a/target/arm/internals.h b/target/arm/internals.h
index f7b641342a..8ec2750847 100644
--- a/target/arm/internals.h
+++ b/target/arm/internals.h
@@ -1808,6 +1808,15 @@ static inline uint64_t arm_mdcr_el2_eff(CPUARMState *env)
     ((1 << (1 - 1)) | (1 << (2 - 1)) |                  \
      (1 << (4 - 1)) | (1 << (8 - 1)) | (1 << (16 - 1)))
 
+/*
+ * Return the maximum SVE/SME VQ for this CPU. This defines
+ * the maximum possible size of the Zn vector registers.
+ */
+static inline int arm_max_vq(ARMCPU *cpu)
+{
+    return MAX(cpu->sve_max_vq, cpu->sme_max_vq);
+}
+
 /*
  * Return true if it is possible to take a fine-grained-trap to EL2.
  */
-- 
2.43.0

[PATCH v2 2/6] target/arm: Report correct vector width in gdbstub when SME present

[Peter Maydell]

Our gdbstub implementation of the org.gnu.gdb.aarch64.sve feature
doesn't account for SME correctly.  We always report the Zn vector
registers with a width based on the maximum SVE vector register size,
even though SME's maximum size could be larger.

This is particularly bad in the case of a CPU with SME but not SVE,
because there the SVE vector width will be zero.  If we report the Zn
registers in the XML as having a zero width then gdb falls over with
an internal error:

 (gdb) target remote :1234
 Remote debugging using :1234
 /build/gdb-1WjiBe/gdb-15.0.50.20240403/gdb/aarch64-tdep.c:3066: internal-error: aarch64_pseudo_register_type: bad register number 160
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.

Report the Zn registers with their correct size.  This matches how we
already handle the 'vg' pseudoregister in org.gnu.gdb.aarch64.sve: we
call sve_vqm1_for_el(), which returns the vector size accounting for
SME, not the pure SVE vector size.

Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
We should make sure we have agreement on the gdb side about
the interpretation of this bit of the protocol. See this
gdb mailing list email:
https://sourceware.org/pipermail/gdb/2026-January/052056.html
---
 target/arm/gdbstub64.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/target/arm/gdbstub64.c b/target/arm/gdbstub64.c
index c584e5b4e6..b71666c3a1 100644
--- a/target/arm/gdbstub64.c
+++ b/target/arm/gdbstub64.c
@@ -158,7 +158,7 @@ int aarch64_gdb_get_sve_reg(CPUState *cs, GByteArray *buf, int reg)
     case 0 ... 31:
     {
         int vq, len = 0;
-        for (vq = 0; vq < cpu->sve_max_vq; vq++) {
+        for (vq = 0; vq < arm_max_vq(cpu); vq++) {
             len += gdb_get_reg128(buf,
                                   env->vfp.zregs[reg].d[vq * 2 + 1],
                                   env->vfp.zregs[reg].d[vq * 2]);
@@ -174,7 +174,7 @@ int aarch64_gdb_get_sve_reg(CPUState *cs, GByteArray *buf, int reg)
     {
         int preg = reg - 34;
         int vq, len = 0;
-        for (vq = 0; vq < cpu->sve_max_vq; vq = vq + 4) {
+        for (vq = 0; vq < arm_max_vq(cpu); vq = vq + 4) {
             len += gdb_get_reg64(buf, env->vfp.pregs[preg].p[vq / 4]);
         }
         return len;
@@ -208,7 +208,7 @@ int aarch64_gdb_set_sve_reg(CPUState *cs, uint8_t *buf, int reg)
     case 0 ... 31:
     {
         int vq, len = 0;
-        for (vq = 0; vq < cpu->sve_max_vq; vq++) {
+        for (vq = 0; vq < arm_max_vq(cpu); vq++) {
             if (target_big_endian()) {
                 env->vfp.zregs[reg].d[vq * 2 + 1] = ldq_p(buf);
                 buf += 8;
@@ -233,7 +233,7 @@ int aarch64_gdb_set_sve_reg(CPUState *cs, uint8_t *buf, int reg)
     {
         int preg = reg - 34;
         int vq, len = 0;
-        for (vq = 0; vq < cpu->sve_max_vq; vq = vq + 4) {
+        for (vq = 0; vq < arm_max_vq(cpu); vq = vq + 4) {
             env->vfp.pregs[preg].p[vq / 4] = ldq_p(buf);
             buf += 8;
             len += 8;
@@ -540,8 +540,8 @@ static void output_vector_union_type(GDBFeatureBuilder *builder, int reg_width,
 GDBFeature *arm_gen_dynamic_svereg_feature(CPUState *cs, int base_reg)
 {
     ARMCPU *cpu = ARM_CPU(cs);
-    int reg_width = cpu->sve_max_vq * 128;
-    int pred_width = cpu->sve_max_vq * 16;
+    int reg_width = arm_max_vq(cpu) * 128;
+    int pred_width = arm_max_vq(cpu) * 16;
     GDBFeatureBuilder builder;
     char *name;
     int reg = 0;
-- 
2.43.0

[PATCH v2 3/6] target/arm: Handle SME-only CPUs in sve_vqm1_for_el_sm()

[Peter Maydell]

In sve_vqm1_for_el_sm(), we implicitly assume that the CPU has SVE:
if called with sm == false for non-streaming mode, we try to return a
vector length from svq_vq.  This hits the "assert(sm)" at the bettom
of the function in an SME-only CPU where sve_vq.map is zero.

Add code to handle the "SME-only CPU not in streaming mode" case: we
report an effective VL of 128 bits, which is what the architecture
rule R_KXKNK says should be used when SVE instructions are disabled
or trapped but floating point instructions are enabled.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 target/arm/helper.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 7ceab0b503..732c3a9eba 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -4763,7 +4763,7 @@ int sme_exception_el(CPUARMState *env, int el)
 }
 
 /*
- * Given that SVE is enabled, return the vector length for EL.
+ * Given that SVE or SME is enabled, return the vector length for EL.
  */
 uint32_t sve_vqm1_for_el_sm(CPUARMState *env, int el, bool sm)
 {
@@ -4775,6 +4775,12 @@ uint32_t sve_vqm1_for_el_sm(CPUARMState *env, int el, bool sm)
     if (sm) {
         cr = env->vfp.smcr_el;
         map = cpu->sme_vq.map;
+    } else if (map == 0) {
+        /*
+         * SME-only CPU not in streaming mode: effective VL
+         * is 128 bits, per R_KXKNK.
+         */
+        return 0;
     }
 
     if (el <= 1 && !el_is_in_host(env, el)) {
-- 
2.43.0

[PATCH v2 4/6] target/arm: Handle SME-without-SVE on change of EL

[Peter Maydell]

aarch64_sve_change_el() currently assumes that SME implies
SVE, and will return without doing anything if SVE is not
implemented, skipping a possible requirement to change
the vector register state because the SME vector length
has changed. Update it to handle SME also.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 target/arm/helper.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index 732c3a9eba..655ce73ee1 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -10127,8 +10127,8 @@ void aarch64_sve_change_el(CPUARMState *env, int old_el,
     int old_len, new_len;
     bool old_a64, new_a64, sm;
 
-    /* Nothing to do if no SVE.  */
-    if (!cpu_isar_feature(aa64_sve, cpu)) {
+    /* Nothing to do if no SVE or SME.  */
+    if (!cpu_isar_feature(aa64_sve, cpu) && !cpu_isar_feature(aa64_sme, cpu)) {
         return;
     }
 
-- 
2.43.0

[PATCH v2 5/6] target/arm: Squash FEAT_SME_FA64 if FEAT_SVE is not present

[Peter Maydell]

FEAT_SME_FA64 allows Streaming SVE code to access the whole
SVE instruction set; it requires FEAT_SVE to be present. If
we have a CPU with SME but not SVE, squash the FA64 bit in
arm_cpu_sme_finalize().

This doesn't have any effect at the moment because we don't
let the user create an SME-without-SVE CPU, but we are about
to lift that restriction.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 target/arm/cpu64.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
index bf30381370..e8c56fc81c 100644
--- a/target/arm/cpu64.c
+++ b/target/arm/cpu64.c
@@ -363,6 +363,11 @@ void arm_cpu_sme_finalize(ARMCPU *cpu, Error **errp)
 
     cpu->sme_vq.map = vq_map;
     cpu->sme_max_vq = 32 - clz32(vq_map);
+
+    if (!cpu_isar_feature(aa64_sve, cpu)) {
+        /* FEAT_SME_FA64 requires SVE, not just SME */
+        FIELD_DP64_IDREG(&cpu->isar, ID_AA64SMFR0, FA64, 0);
+    }
 }
 
 static bool cpu_arm_get_sme(Object *obj, Error **errp)
-- 
2.43.0

[PATCH v2 6/6] target/arm: Permit configurations with SME but not SVE

[Peter Maydell]

In commit f7767ca30179 ("target/arm: Disable SME if SVE is disabled")
we added code that forces SME to be disabled if SVE is disabled.
This was something we did in the run-up to a release to avoid an
assertion failure in smcr_write() if the user disabled SVE on the
'max' CPU without disabling SME also.

Now that we have corrected the code so that it doesn't assert
in an SME-without-SVE setup, we can let users select it.

This effectively reverts f7767ca30179.

Note that this now means that command lines like "-cpu max,sve=off"
which used to turn off SME and SVE will now give you a CPU with SME
but not SVE.  This is permitted by our loose "max can always give you
extra stuff" rules, but may be unexpected to users.  Mention this in
the CPU property documentation.

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 docs/system/arm/cpu-features.rst | 10 ++++++++--
 target/arm/cpu.c                 | 10 ----------
 2 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/docs/system/arm/cpu-features.rst b/docs/system/arm/cpu-features.rst
index 37d5dfd15b..9d0c5731cc 100644
--- a/docs/system/arm/cpu-features.rst
+++ b/docs/system/arm/cpu-features.rst
@@ -318,12 +318,18 @@ SVE CPU Property Parsing Semantics
      provided an error will be generated.  To avoid this error, one must
      enable at least one vector length prior to enabling SVE.
 
+  10) Disabling SVE does not automatically disable SME. If you want to
+      disable both you must use ``sve=off,sme=off``. In particular,
+      for the ``max`` CPU, ``sve=off`` alone will give you a CPU with
+      SME only (and which therefore still has the SVE vector registers).
+      Most users will want to disable both at once.
+
 SVE CPU Property Examples
 -------------------------
 
-  1) Disable SVE::
+  1) Disable SVE and SME::
 
-     $ qemu-system-aarch64 -M virt -cpu max,sve=off
+     $ qemu-system-aarch64 -M virt -cpu max,sve=off,sme=off
 
   2) Implicitly enable all vector lengths for the ``max`` CPU type::
 
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 6e1cbf3d61..1cb30076ad 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -1571,16 +1571,6 @@ void arm_cpu_finalize_features(ARMCPU *cpu, Error **errp)
             return;
         }
 
-        /*
-         * FEAT_SME is not architecturally dependent on FEAT_SVE (unless
-         * FEAT_SME_FA64 is present). However our implementation currently
-         * 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)) {
-            object_property_set_bool(OBJECT(cpu), "sme", false, &error_abort);
-        }
-
         arm_cpu_sme_finalize(cpu, &local_err);
         if (local_err != NULL) {
             error_propagate(errp, local_err);
-- 
2.43.0

Re: [PATCH v2 1/6] target/arm: Account for SME in aarch64_sve_narrow_vq() assertion

[Philippe Mathieu-Daudé]

On 29/1/26 12:34, Peter Maydell wrote:
> In aarch64_sve_narrow_vq() we assert that the new VQ is within
> the maximum supported range for the CPU. We forgot to update
> this to account for SME, which might have a different maximum.
> 
> Update the assert to permit any VQ which is valid for either
> SVE or SME.
> 
> Cc: qemu-stable@nongnu.org
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> CC stable on this one, because it might also be a problem for
> a CPU with both SME and SVE but where the SVE max VL is less
> than the SME max VL.
> ---
>   target/arm/helper.c    | 2 +-
>   target/arm/internals.h | 9 +++++++++
>   2 files changed, 10 insertions(+), 1 deletion(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH v2 2/6] target/arm: Report correct vector width in gdbstub when SME present

[Philippe Mathieu-Daudé]

On 29/1/26 12:34, Peter Maydell wrote:
> Our gdbstub implementation of the org.gnu.gdb.aarch64.sve feature
> doesn't account for SME correctly.  We always report the Zn vector
> registers with a width based on the maximum SVE vector register size,
> even though SME's maximum size could be larger.
> 
> This is particularly bad in the case of a CPU with SME but not SVE,
> because there the SVE vector width will be zero.  If we report the Zn
> registers in the XML as having a zero width then gdb falls over with
> an internal error:
> 
>   (gdb) target remote :1234
>   Remote debugging using :1234
>   /build/gdb-1WjiBe/gdb-15.0.50.20240403/gdb/aarch64-tdep.c:3066: internal-error: aarch64_pseudo_register_type: bad register number 160
>   A problem internal to GDB has been detected,
>   further debugging may prove unreliable.
> 
> Report the Zn registers with their correct size.  This matches how we
> already handle the 'vg' pseudoregister in org.gnu.gdb.aarch64.sve: we
> call sve_vqm1_for_el(), which returns the vector size accounting for
> SME, not the pure SVE vector size.
> 
> Cc: qemu-stable@nongnu.org
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> We should make sure we have agreement on the gdb side about
> the interpretation of this bit of the protocol. See this
> gdb mailing list email:
> https://sourceware.org/pipermail/gdb/2026-January/052056.html
> ---
>   target/arm/gdbstub64.c | 12 ++++++------
>   1 file changed, 6 insertions(+), 6 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH v2 4/6] target/arm: Handle SME-without-SVE on change of EL

[Philippe Mathieu-Daudé]

On 29/1/26 12:34, Peter Maydell wrote:
> aarch64_sve_change_el() currently assumes that SME implies
> SVE, and will return without doing anything if SVE is not
> implemented, skipping a possible requirement to change
> the vector register state because the SME vector length
> has changed. Update it to handle SME also.
> 
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>   target/arm/helper.c | 4 ++--
>   1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index 732c3a9eba..655ce73ee1 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -10127,8 +10127,8 @@ void aarch64_sve_change_el(CPUARMState *env, int old_el,

Could we rename the method? Maybe aarch64_vq_change_el()?

>       int old_len, new_len;
>       bool old_a64, new_a64, sm;
>   
> -    /* Nothing to do if no SVE.  */
> -    if (!cpu_isar_feature(aa64_sve, cpu)) {
> +    /* Nothing to do if no SVE or SME.  */
> +    if (!cpu_isar_feature(aa64_sve, cpu) && !cpu_isar_feature(aa64_sme, cpu)) {
>           return;
>       }
>   

Re: [PATCH v2 1/6] target/arm: Account for SME in aarch64_sve_narrow_vq() assertion

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> In aarch64_sve_narrow_vq() we assert that the new VQ is within
> the maximum supported range for the CPU. We forgot to update
> this to account for SME, which might have a different maximum.
>
> Update the assert to permit any VQ which is valid for either
> SVE or SME.
>
> Cc: qemu-stable@nongnu.org
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 2/6] target/arm: Report correct vector width in gdbstub when SME present

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> Our gdbstub implementation of the org.gnu.gdb.aarch64.sve feature
> doesn't account for SME correctly.  We always report the Zn vector
> registers with a width based on the maximum SVE vector register size,
> even though SME's maximum size could be larger.
>
> This is particularly bad in the case of a CPU with SME but not SVE,
> because there the SVE vector width will be zero.  If we report the Zn
> registers in the XML as having a zero width then gdb falls over with
> an internal error:
>
>  (gdb) target remote :1234
>  Remote debugging using :1234
>  /build/gdb-1WjiBe/gdb-15.0.50.20240403/gdb/aarch64-tdep.c:3066: internal-error: aarch64_pseudo_register_type: bad register number 160
>  A problem internal to GDB has been detected,
>  further debugging may prove unreliable.
>
> Report the Zn registers with their correct size.  This matches how we
> already handle the 'vg' pseudoregister in org.gnu.gdb.aarch64.sve: we
> call sve_vqm1_for_el(), which returns the vector size accounting for
> SME, not the pure SVE vector size.
>
> Cc: qemu-stable@nongnu.org
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 3/6] target/arm: Handle SME-only CPUs in sve_vqm1_for_el_sm()

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> In sve_vqm1_for_el_sm(), we implicitly assume that the CPU has SVE:
> if called with sm == false for non-streaming mode, we try to return a
> vector length from svq_vq.  This hits the "assert(sm)" at the bettom
> of the function in an SME-only CPU where sve_vq.map is zero.
>
> Add code to handle the "SME-only CPU not in streaming mode" case: we
> report an effective VL of 128 bits, which is what the architecture
> rule R_KXKNK says should be used when SVE instructions are disabled
> or trapped but floating point instructions are enabled.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 4/6] target/arm: Handle SME-without-SVE on change of EL

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> aarch64_sve_change_el() currently assumes that SME implies
> SVE, and will return without doing anything if SVE is not
> implemented, skipping a possible requirement to change
> the vector register state because the SME vector length
> has changed. Update it to handle SME also.
>
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 6/6] target/arm: Permit configurations with SME but not SVE

[Alex Bennée]

Peter Maydell <peter.maydell@linaro.org> writes:

> In commit f7767ca30179 ("target/arm: Disable SME if SVE is disabled")
> we added code that forces SME to be disabled if SVE is disabled.
> This was something we did in the run-up to a release to avoid an
> assertion failure in smcr_write() if the user disabled SVE on the
> 'max' CPU without disabling SME also.
>
> Now that we have corrected the code so that it doesn't assert
> in an SME-without-SVE setup, we can let users select it.
>
> This effectively reverts f7767ca30179.
>
> Note that this now means that command lines like "-cpu max,sve=off"
> which used to turn off SME and SVE will now give you a CPU with SME
> but not SVE.  This is permitted by our loose "max can always give you
> extra stuff" rules, but may be unexpected to users.  Mention this in
> the CPU property documentation.
>
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>  docs/system/arm/cpu-features.rst | 10 ++++++++--
>  target/arm/cpu.c                 | 10 ----------
>  2 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/docs/system/arm/cpu-features.rst b/docs/system/arm/cpu-features.rst
> index 37d5dfd15b..9d0c5731cc 100644
> --- a/docs/system/arm/cpu-features.rst
> +++ b/docs/system/arm/cpu-features.rst
> @@ -318,12 +318,18 @@ SVE CPU Property Parsing Semantics
>       provided an error will be generated.  To avoid this error, one must
>       enable at least one vector length prior to enabling SVE.
>  
> +  10) Disabling SVE does not automatically disable SME. If you want to
> +      disable both you must use ``sve=off,sme=off``. In particular,
> +      for the ``max`` CPU, ``sve=off`` alone will give you a CPU with
> +      SME only (and which therefore still has the SVE vector registers).
> +      Most users will want to disable both at once.
> +
>  SVE CPU Property Examples
>  -------------------------
>  
> -  1) Disable SVE::
> +  1) Disable SVE and SME::
>  
> -     $ qemu-system-aarch64 -M virt -cpu max,sve=off
> +     $ qemu-system-aarch64 -M virt -cpu max,sve=off,sme=off
>  
>    2) Implicitly enable all vector lengths for the ``max`` CPU type::


Reviewed-by: Alex Bennée <alex.bennee@linaro.org>

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [PATCH v2 1/6] target/arm: Account for SME in aarch64_sve_narrow_vq() assertion

[Richard Henderson]

On 1/29/26 21:34, Peter Maydell wrote:
> In aarch64_sve_narrow_vq() we assert that the new VQ is within
> the maximum supported range for the CPU. We forgot to update
> this to account for SME, which might have a different maximum.
> 
> Update the assert to permit any VQ which is valid for either
> SVE or SME.
> 
> Cc:qemu-stable@nongnu.org
> Signed-off-by: Peter Maydell<peter.maydell@linaro.org>
> ---
> CC stable on this one, because it might also be a problem for
> a CPU with both SME and SVE but where the SVE max VL is less
> than the SME max VL.
> ---
>   target/arm/helper.c    | 2 +-
>   target/arm/internals.h | 9 +++++++++
>   2 files changed, 10 insertions(+), 1 deletion(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH v2 3/6] target/arm: Handle SME-only CPUs in sve_vqm1_for_el_sm()

[Richard Henderson]

On 1/29/26 21:34, Peter Maydell wrote:
> In sve_vqm1_for_el_sm(), we implicitly assume that the CPU has SVE:
> if called with sm == false for non-streaming mode, we try to return a
> vector length from svq_vq.  This hits the "assert(sm)" at the bettom
> of the function in an SME-only CPU where sve_vq.map is zero.
> 
> Add code to handle the "SME-only CPU not in streaming mode" case: we
> report an effective VL of 128 bits, which is what the architecture
> rule R_KXKNK says should be used when SVE instructions are disabled
> or trapped but floating point instructions are enabled.
> 
> Signed-off-by: Peter Maydell<peter.maydell@linaro.org>
> ---
>   target/arm/helper.c | 8 +++++++-
>   1 file changed, 7 insertions(+), 1 deletion(-)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~

Re: [PATCH v2 5/6] target/arm: Squash FEAT_SME_FA64 if FEAT_SVE is not present

[Richard Henderson]

On 1/29/26 21:34, Peter Maydell wrote:
> FEAT_SME_FA64 allows Streaming SVE code to access the whole
> SVE instruction set; it requires FEAT_SVE to be present. If
> we have a CPU with SME but not SVE, squash the FA64 bit in
> arm_cpu_sme_finalize().
> 
> This doesn't have any effect at the moment because we don't
> let the user create an SME-without-SVE CPU, but we are about
> to lift that restriction.
> 
> Signed-off-by: Peter Maydell<peter.maydell@linaro.org>
> ---
>   target/arm/cpu64.c | 5 +++++
>   1 file changed, 5 insertions(+)

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

r~