On Mon, Jan 05 2026, Richard Henderson <[email protected]> wrote:
> 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? The idea was to move all of the ID registers into the idregs array eventually, to be prepared for switching to an automatically generated cpu-sysregs.h.inc. (Still remaining after this patch are CCSIDR* and friends.) I'm not sure if KVM will support DCZID_EL0 anytime soon, but if that happens, it will be easier to integrate. > > You could usefully split this patch, introducing the get/set helpers before > changing the > representation. Can do that.
