From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DQ4AY-0003Ha-Hd for qemu-devel@nongnu.org; Mon, 25 Apr 2005 10:02:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DQ4AW-0003GZ-PF for qemu-devel@nongnu.org; Mon, 25 Apr 2005 10:02:38 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DQ4AW-0003FJ-I4 for qemu-devel@nongnu.org; Mon, 25 Apr 2005 10:02:36 -0400 Received: from [213.21.189.59] (helo=mingus.dizzy.lan) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DQ4AF-0007Xe-BZ for qemu-devel@nongnu.org; Mon, 25 Apr 2005 10:02:20 -0400 Received: from d600.dizzy.lan ([192.168.1.2] helo=localhost.localdomain) by mingus.dizzy.lan with esmtp (Exim 3.35 #1 (Debian)) id 1DQ46g-0001c8-00 for ; Mon, 25 Apr 2005 15:58:38 +0200 Date: Mon, 25 Apr 2005 13:15:32 +0200 From: Massimo Dal Zotto Message-ID: <20050425111532.GA2554@dizzy.ath.cx> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline Subject: [Qemu-devel] [patch] option -no-tsc for i386 with speedstep Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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. -- Massimo Dal Zotto --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="qemu-notsc.patch" --- qemu-0.6.2cvs20050425.orig/vl.c 2005-04-08 00:20:28.000000000 +0200 +++ qemu-0.6.2cvs20050425/vl.c 2005-04-25 11:44:41.119819832 +0200 @@ -135,6 +135,10 @@ int prep_enabled = 0; int rtc_utc = 1; int cirrus_vga_enabled = 1; +#ifdef __i386__ +static int notsc = 0; +extern int64_t get_clock(void); +#endif #ifdef TARGET_SPARC int graphic_width = 1024; int graphic_height = 768; @@ -502,6 +506,9 @@ int64_t cpu_get_real_ticks(void) { int64_t val; + if (notsc) { + return get_clock(); + } asm volatile ("rdtsc" : "=A" (val)); return val; } @@ -2792,6 +2799,9 @@ #ifdef USE_CODE_COPY "-no-code-copy disable code copy acceleration\n" #endif +#ifdef __i386__ + "-no-tsc disable tsc as clock source\n" +#endif #ifdef TARGET_I386 "-isa simulate an ISA-only system (default is PCI system)\n" "-std-vga simulate a standard VGA card with VESA Bochs Extensions\n" @@ -2863,6 +2873,7 @@ QEMU_OPTION_hdachs, QEMU_OPTION_L, QEMU_OPTION_no_code_copy, + QEMU_OPTION_no_tsc, QEMU_OPTION_pci, QEMU_OPTION_isa, QEMU_OPTION_prep, @@ -2931,6 +2942,9 @@ #ifdef USE_KQEMU { "no-kqemu", 0, QEMU_OPTION_no_kqemu }, #endif +#ifdef __i386__ + { "no-tsc", 0, QEMU_OPTION_no_tsc }, +#endif #ifdef TARGET_PPC { "prep", 0, QEMU_OPTION_prep }, #endif @@ -3216,6 +3230,11 @@ case QEMU_OPTION_no_code_copy: code_copy_enabled = 0; break; +#ifdef __i386__ + case QEMU_OPTION_no_tsc: + notsc = 1; + break; +#endif case QEMU_OPTION_nics: nb_nics = atoi(optarg); if (nb_nics < 0 || nb_nics > MAX_NICS) { --bp/iNruPH9dso1Pn--