qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.

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