On Fri, 19 Apr 2024 at 19:46, Peter Maydell <peter.mayd...@linaro.org> wrote: > > In previous versions of the Arm architecture, the frequency of the > generic timers as reported in CNTFRQ_EL0 could be any IMPDEF value, > and for QEMU we picked 62.5MHz, giving a timer tick period of 16ns. > In Armv8.6, the architecture standardized this frequency to 1GHz. > > Because there is no ID register feature field that indicates whether a > CPU is v8.6 or that it ought to have this counter frequency, we > implement this by changing our default CNTFRQ value for all CPUs, with > exceptions for backwards compatibility: > > * CPU types which we already implement will retain the old > default value. None of these are v8.6 CPUs, so this is > architecturally OK. > * CPUs used in versioned machine types with a version of 9.0 > or earlier will retain the old default value. > > The upshot is that the only CPU type that changes is 'max'; but any > new type we add in future (whether v8.6 or not) will also get the new > 1GHz default (assuming we spot in code review any attempts to set > the ARM_FEATURE_BACKCOMPAT_CNTFRQ flag on new CPU types as a result > of cut-n-paste from an older CPU initfn ;-)). > > It remains the case that the machine model can override the default > value via the 'cntfrq' QOM property (regardless of the CPU type).
This patchset turns out to break the sbsa-ref board: the Aarch64SbsarefMachine.test_sbsaref_alpine_linux_max_pauth_impdef avocado test both (a) takes rather longer to boot and (b) when running thinks that time is advancing very fast. I suspect this may be because the firmware hard-codes the generic timer clock frequency it is expecting. I've cc'd the sbsa-ref maintainers: is that correct? If so, we can deal with it by making the sbsa-ref board set the cntfrq QOM property on its CPUs to force them to the old frequency. However this will produce a technically-out-of-spec CPU when used with a v8.6-compliant CPU type, so probably we should do something to be able to tell the firmware the clock frequency (if it doesn't want to just read CNTFRQ_EL0 itself). thanks -- PMM