On 03/10/2015 00:41, Peter Maydell wrote: > > What I meant to ask was, do you see any reason for cpu_get_ticks() to exist? > > If no architecture besides i386 wants to use it, perhaps the code should be > > moved there. > > 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. They are also similar in that both cpu_get_ticks() and QEMU_CLOCK_VIRTUAL "morph" to the instruction count in icount mode. cpu_get_ticks() should be the right implementation for the ARM PMCCNTR cycle counter, since: 1) PMCCNTR is roughly the same as the x86 RDTSC; 2) cpu_get_ticks() is the only monotonically increasing value outside icount mode. Paolo
