On 11/28/25 04:06, Cornelia Huck wrote:
This requires a bit of care, since we still have to handle the EL
specific part (DCZID_EL0.DZP). Callers can set/access dcz_blocksize
via a wrapper working on DCZID_EL.BS.

KVM currently does not support DCZID_EL0 via ONE_REG, assert that
we're not trying to do anything with it until it does.

Signed-off-by: Cornelia Huck <[email protected]>
---
Changes v1 -> v2:
- use extract64/deposit64, tweak helper names
- assert that we're not using the reg while running under kvm, instead
   of providing an incorrect dummy value
---
  target/arm/cpu-sysregs.h.inc   |  1 +
  target/arm/cpu.c               |  2 +-
  target/arm/cpu.h               | 14 ++++++++++++--
  target/arm/cpu64.c             |  4 ++--
  target/arm/helper.c            |  5 ++++-
  target/arm/tcg/cpu64.c         | 22 +++++++++++-----------
  target/arm/tcg/helper-a64.c    |  2 +-
  target/arm/tcg/mte_helper.c    |  4 ++--
  target/arm/tcg/translate-a64.c |  2 +-
  target/arm/tcg/translate.h     |  2 +-
  10 files changed, 36 insertions(+), 22 deletions(-)

diff --git a/target/arm/cpu-sysregs.h.inc b/target/arm/cpu-sysregs.h.inc
index 2bb2861c6234..7f3aa8b991aa 100644
--- a/target/arm/cpu-sysregs.h.inc
+++ b/target/arm/cpu-sysregs.h.inc
@@ -39,3 +39,4 @@ DEF(ID_MMFR5_EL1, 3, 0, 0, 3, 6)
  DEF(CLIDR_EL1, 3, 1, 0, 0, 1)
  DEF(ID_AA64ZFR0_EL1, 3, 0, 0, 4, 4)
  DEF(CTR_EL0, 3, 3, 0, 0, 1)
+DEF(DCZID_EL0, 3, 3, 0, 0, 7)
diff --git a/target/arm/cpu.c b/target/arm/cpu.c
index 39292fb9bc1f..557af43a9709 100644
--- a/target/arm/cpu.c
+++ b/target/arm/cpu.c
@@ -2184,7 +2184,7 @@ static void arm_cpu_realizefn(DeviceState *dev, Error 
**errp)
  #endif
if (tcg_enabled()) {
-        int dcz_blocklen = 4 << cpu->dcz_blocksize;
+        int dcz_blocklen = 4 << get_dczid_bs(cpu);
/*
           * We only support DCZ blocklen that fits on one page.
diff --git a/target/arm/cpu.h b/target/arm/cpu.h
index 39f2b2e54deb..32f003705551 100644
--- a/target/arm/cpu.h
+++ b/target/arm/cpu.h
@@ -1111,8 +1111,6 @@ struct ArchCPU {
      bool prop_pauth_qarma5;
      bool prop_lpa2;
- /* DCZ blocksize, in log_2(words), ie low 4 bits of DCZID_EL0 */
-    uint8_t dcz_blocksize;
      /* GM blocksize, in log_2(words), ie low 4 bits of GMID_EL0 */
      uint8_t gm_blocksize;
@@ -1178,6 +1176,18 @@ struct ARMCPUClass {
      ResettablePhases parent_phases;
  };
+static inline uint8_t get_dczid_bs(ARMCPU *cpu)
+{
+    return extract64(cpu->isar.idregs[DCZID_EL0_IDX], 0, 4);
+}
+
+static inline void set_dczid_bs(ARMCPU *cpu, uint8_t bs)
+{
+    /* keep dzp unchanged */
+    cpu->isar.idregs[DCZID_EL0_IDX] =
+        deposit64(cpu->isar.idregs[DCZID_EL0_IDX], 0, 4, bs);
+}

Given that dzp is always computed, I don't see the point of this. Or... is the point that KVM *will* eventually support DCZID_EL0, and we won't be computing DZP along the KVM trap-and-read path?

You could usefully split this patch, introducing the get/set helpers before changing the representation.

r~

Reply via email to