qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3 03/15] target/arm: Do not use aarch64_sve_zcr_get_valid_le


From: Richard Henderson
Subject: Re: [PATCH v3 03/15] target/arm: Do not use aarch64_sve_zcr_get_valid_len in reset
Date: Tue, 31 May 2022 07:28:18 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

On 5/31/22 05:15, Peter Maydell wrote:
On Fri, 27 May 2022 at 19:07, Richard Henderson
<richard.henderson@linaro.org> wrote:

We don't need to constrain the value set in zcr_el[1],
because it will be done by sve_zcr_len_for_el.

Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
---
  target/arm/cpu.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index d2bd74c2ed..0621944167 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -208,8 +208,7 @@ static void arm_cpu_reset(DeviceState *dev)
                                           CPACR_EL1, ZEN, 3);
          /* with reasonable vector length */
          if (cpu_isar_feature(aa64_sve, cpu)) {
-            env->vfp.zcr_el[1] =
-                aarch64_sve_zcr_get_valid_len(cpu, cpu->sve_default_vq - 1);
+            env->vfp.zcr_el[1] = cpu->sve_default_vq - 1;
          }

I'm still not a fan of the zcr_el[] value not actually being
a valid one. I'd rather we constrained it when we write the
value into the field.

It is an architecturally valid value, exactly like the kernel might write while probing for supported vector lengths. It will result in this, or the next smaller supported vector size, being selected.


r~



reply via email to

[Prev in Thread] Current Thread [Next in Thread]