[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Fabrice Bellard
Subject: Re: [Qemu-devel] [patch] option -no-tsc for i386 with speedstep
Date: Mon, 25 Apr 2005 20:58:06 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913

Massimo Dal Zotto wrote:
When qemu runs on an i386 cpu with speedstep enabled the clock of the
guest os is not in sync with the clock on the host os because the
vm_timer used for irq 0 generates interrupts at wrong rate when
the host cpu frequency changes.

The problem is that the vm_timer uses the rdtsc instruction and the value
of ticks_per_sec, computed at start time, for calculating the expire time
of vm_timers. While ticks_per_sec is constant the values returned by
rdtsc are dependent on the current cpu clock, which is not constant if
speedstep is used.

The problem can be cleary observed by running "xclock -update 1" in the
guest os and observing how the clock speed varies with the cpu freqency.

The following patch fixes the problem by adding a new option -no-tsc for
the i386 architecture which can be used to disable rdtsc when running on
a cpu with speedstep enabled.

The patch works for me but I don't know if this is the best way of fixing
this bug. If anyone has a better suggestion it is welcome.

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.

- 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.

- 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 !).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]