On 05/10/2015 16:11, Peter Maydell wrote: > > > OTOH various non-x86 things do use the closely related > > > cpu_get_real_ticks(), > > > and the implementation of cpu_get_ticks() is very closely related to > > > the other clock code in cpus.c. > > > > cpu_get_real_ticks() is returning the host cycle counter; > > cpu_get_ticks() is stopping/resuming it when the VM is stopped/resumed. > > In other words, cpu_get_real_ticks() is to cpu_get_ticks() what > > QEMU_CLOCK_REALTIME is to QEMU_CLOCK_VIRTUAL. > > ...but it seems wrong to have anything in the simulation care > about the host cycle counter,
I agree; instruction count is much better. Unfortunately, -icount has a relatively hefty performance penalty. It is also common that code using PMCCNTR/RDTSC wants the increment between two reads to be large-ish and at least remotely related to the number of instructions that were executed in between. I've also used rdtsc in the guest from time to time to benchmark changes to TCG. Having it map to the host cycle counter is somewhat useful for that purpose, though one might say this usecase is niche. > especially since on some hosts > the underlying implementation is terrible. I remember seeing a bug where this terrible implementation caused divisions by zero on the host. The default implementation in include/qemu/timer.h should be changed to qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL). Note that in practice this terrible implementation is only used on ARM/AArch64. Is PMCCNTR or something similar accessible from userspace? I guess no, since even write access is enabled via PMUSERENR (and in general PMUSERENR ought to be false on a preemptive-multitasking OS). In the end I guess qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) would work just as well for PMCCNTR, but I think non-Linux OSes still have a relatively slow clock_gettime() so there is still an advantage in using cpu_get_ticks(). Paolo ps: on x86, a long time ago rdtsc was reliable and clock_gettime() was slow, so it was a no-brainer for benchmarks and the like; then rdtsc became unreliable and clock_gettime() became fast on Linux; but now at least on new machines rdtsc is usually reliable again.
