mirror of
https://github.com/qemu/qemu.git
synced 2024-12-04 09:13:39 +08:00
96eec6b2b3
The ASPEED AST2600 clocks the generic timer at the rate of HPLL. On recent firmwares this is at 1125MHz, which is considerably quicker than the assumed 62.5MHz of the current generic timer implementation. The delta between the value as read from CNTFRQ and the true rate of the underlying QEMUTimer leads to sticky behaviour in AST2600 guests. Add a feature-gated property exposing CNTFRQ for ARM CPUs providing the generic timer. This allows platforms to configure CNTFRQ (and the associated QEMUTimer) to the appropriate frequency prior to starting the guest. As the platform can now determine the rate of CNTFRQ we're exposed to limitations of QEMUTimer that didn't previously materialise: In the course of emulation we need to arbitrarily and accurately convert between guest ticks and time, but we're constrained by QEMUTimer's use of an integer scaling factor. The effect is QEMUTimer cannot exactly capture the period of frequencies that do not cleanly divide NANOSECONDS_PER_SECOND for scaling ticks to time. As such, provide an equally inaccurate scaling factor for scaling time to ticks so at least a self-consistent inverse relationship holds. Signed-off-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: a22db9325f96e39f76e3c2baddcb712149f46bf2.1576215453.git-series.andrew@aj.id.au Signed-off-by: Peter Maydell <peter.maydell@linaro.org> |
||
|---|---|---|
| .. | ||
| alpha | ||
| arm | ||
| cris | ||
| hppa | ||
| i386 | ||
| lm32 | ||
| m68k | ||
| microblaze | ||
| mips | ||
| moxie | ||
| nios2 | ||
| openrisc | ||
| ppc | ||
| riscv | ||
| s390x | ||
| sh4 | ||
| sparc | ||
| tilegx | ||
| tricore | ||
| unicore32 | ||
| xtensa | ||