From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EZW3r-0001rX-81 for qemu-devel@nongnu.org; Tue, 08 Nov 2005 11:11:03 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EZW3o-0001pM-Pw for qemu-devel@nongnu.org; Tue, 08 Nov 2005 11:11:02 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EZW3o-0001ol-88 for qemu-devel@nongnu.org; Tue, 08 Nov 2005 11:11:00 -0500 Received: from [213.165.64.20] (helo=mail.gmx.net) by monty-python.gnu.org with smtp (Exim 4.34) id 1EZW3n-0000Bz-P0 for qemu-devel@nongnu.org; Tue, 08 Nov 2005 11:11:00 -0500 Subject: Re: [Qemu-devel] Re: Timing problems From: Sven Zenker In-Reply-To: References: Content-Type: text/plain Date: Tue, 08 Nov 2005 10:24:59 -0500 Message-Id: <1131463500.10016.22.camel@linux> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Hi, people have had this problem with SpeedStep machines, where it is related to qemu timing being based on CPU cycle count, which is thereby messed up. Since it seems to occur with frequency scaling disabled as well, could this be related to running on a HyperThreading CPU? Not sure what happens there with the cycle counts, but to verify, you could try to apply my previously posted patch that substituted the built-in mechanism with realtime clock calls (was for 0.7.1, though, I think). Best, Sven Am Montag, den 07.11.2005, 22:46 +0000 schrieb Michael Smith: > Alexander Toresson gmail.com> writes: > > > time flies by at 5x the speed it should. > > > PS. I'm susprised nobody has seen this problem before. Is it just me > > who experience it? > > No, I experience this as well. > > I'm running Qemu 0.7.2 with Linux 2.6.14 (vanilla kernel) as host OS and Windows > XP Professional as guest OS. If the VM is running and actively using CPU, time > runs much faster in the guest than in the host. On the other hand, if the VM is > mostly idle, time is slower in the guest than in the host OS. > > This odd clock behavior seems to cause other problems in the guest OS, > particularly during boot/service initialization. > > I can recreate this behavior with or without KQemu. > > I can recreate this behavior with or without CPU frequency scaling enabled. > > It is frustrating, and I would be very happy if someone could suggest a fix or > workaround. > > Thanks, > Mike Smith > mas3f@alumni.virginia.edu > > > > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel >