On 10/13/25 09:10, Peter Maydell wrote:
In commit bd8e9ddf6f6 ("target/arm: Refactor default generic timer frequency handling") we changed how we initialized the generic timer frequency as reported in the CNTFRQ_EL0 register. As part of that, we chanegd the linux-user version of the CNTFRQ_EL0 sysreg from having a constant value set at compile time through the .resetvalue field to having a reset value which we compute in a .resetfn.This accidentally broke the reading of CNTFRQ_EL0 in linux-user mode, because the cpreg is marked as ARM_CP_CONST, which means we translate it as a read of the compile-time constant value in the .resetvalue field. This is now zero, so userspace sees a 0 frequency value. Fix the bug by dropping the ARM_CP_CONST marking. This will cause us to translate the read as a load of the value from the CPU state struct cp15.c14_cntfrq field, which is where the real frequency value now lives. Cc: [email protected] Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3159 Fixes: bd8e9ddf6f6 ("target/arm: Refactor default generic timer frequency handling") Signed-off-by: Peter Maydell <[email protected]> --- target/arm/helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/arm/helper.c b/target/arm/helper.c index 167f2909b3f..1e1c0e41415 100644 --- a/target/arm/helper.c +++ b/target/arm/helper.c @@ -2306,7 +2306,7 @@ static uint64_t gt_virt_cnt_read(CPUARMState *env, const ARMCPRegInfo *ri) static const ARMCPRegInfo generic_timer_cp_reginfo[] = { { .name = "CNTFRQ_EL0", .state = ARM_CP_STATE_AA64, .opc0 = 3, .opc1 = 3, .crn = 14, .crm = 0, .opc2 = 0, - .type = ARM_CP_CONST, .access = PL0_R /* no PL1_RW in linux-user */, + .access = PL0_R /* no PL1_RW in linux-user */, .fieldoffset = offsetof(CPUARMState, cp15.c14_cntfrq), .resetfn = arm_gt_cntfrq_reset, },
Reviewed-by: Richard Henderson <[email protected]> r~
