Re: [Qemu-devel] [patch] option -no-tsc for i386 with speedstep

[Massimo Dal Zotto <dz@debian.org>]

On Mon, Apr 25, 2005 at 08:58:06PM +0200, Fabrice Bellard wrote:
> 
> This is not the best way to fix the bug. I see 4 solutions:
> 
> - Compute ticks_per_sec every n seconds and update the timers accordingly.

This won't work well if an userpace scaling governor is continuously
changing the cpu frequency depending on system load (which is often
generated by qemu itself) as happens on my laptop.

> - Use a virtual cycle counter and update ticks_per_sec dynamically. This 
> solution has the advantage of not needing any precise host timer (= very 
> portable), but it will slow down QEMU a bit.

How could a virtual cycle counter measure real time with accuracy?

> - Use a specific driver to get the time efficiently (= without system 
> call) or to know when the host frequency changes
> 
> - Disable speedstep or use a CPU for which the rdtsc period does not 
> vary even if the CPU frequency changes (the P4 has this feature if I 
> remember correctly and all well designed CPUs should have such a feature !).

Speedstep is needed to save battery charge and my cpu, which is a
recent centrino, returns a variable rdtsc result. We are condemned
to use whichever cpu laptop makers decide to put in our laptops.

The tsc timer code in kernel 2.6 has an algorithm to compute a constant
clock rate from a variable tsc but I don't know how this could be ported
in user space. Could this code be reused, maybe with the help of kqemu?

In the meantime until we find a better solution could you give us some
explanation on why using a microseconds clock from gettimeofday instead
of rdtsc the guest os clock runs always 20% slower?

Having an almost precise system clock is a normal requirement and I
believe than even a sub-optimal solution would be better than a
constantly wrong clock like many of us are experiencing.

-- 
Massimo Dal Zotto