From: Fabrice Bellard <fabrice@bellard.org>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [patch] option -no-tsc for i386 with speedstep
Date: Mon, 25 Apr 2005 20:58:06 +0200 [thread overview]
Message-ID: <426D3DBE.9080307@bellard.org> (raw)
In-Reply-To: <20050425111532.GA2554@dizzy.ath.cx>
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 !).
Fabrice.
next prev parent reply other threads:[~2005-04-25 18:59 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-25 11:15 [Qemu-devel] [patch] option -no-tsc for i386 with speedstep Massimo Dal Zotto
2005-04-25 15:44 ` [Qemu-devel] " Heike C. Zimmerer
2005-04-25 17:07 ` [Qemu-devel] " Jim C. Brown
2005-04-25 17:28 ` Paul Brook
2005-04-25 17:44 ` Massimo Dal Zotto
2005-04-25 17:47 ` [Qemu-devel] " Heike C. Zimmerer
2005-04-25 18:58 ` Fabrice Bellard [this message]
2005-04-25 20:17 ` [Qemu-devel] " Massimo Dal Zotto
2005-04-25 20:24 ` Jonas Maebe
2005-04-25 20:38 ` Filip Navara
2005-04-25 21:03 ` Lionel Ulmer
2005-04-25 22:45 ` Taras Glek
2005-04-25 21:46 ` [Qemu-devel] [patch] option -no-tsc for i386 with speedstep (solved) Massimo Dal Zotto
2005-04-26 6:50 ` Jonas Maebe
2005-04-26 3:03 ` [Qemu-devel] [patch] option -no-tsc for i386 with speedstep Kyle Hayes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=426D3DBE.9080307@bellard.org \
--to=fabrice@bellard.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).