From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54106) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VR37B-0007ZN-VA for qemu-devel@nongnu.org; Tue, 01 Oct 2013 12:48:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VR374-0007OZ-2b for qemu-devel@nongnu.org; Tue, 01 Oct 2013 12:48:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:49223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VR373-0007OU-Qz for qemu-devel@nongnu.org; Tue, 01 Oct 2013 12:47:54 -0400 Date: Tue, 1 Oct 2013 19:47:49 +0300 From: Gleb Natapov Message-ID: <20131001164749.GV11993@redhat.com> References: <20100629211802.16137.10587.malonedeb@soybean.canonical.com> <20131001093406.22350.79125.malone@soybean.canonical.com> <20131001155645.GR11993@redhat.com> <20131001163317.GT11993@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [Bug 599958] Re: Timedrift problems with Win7: hpet missing time drift fixups List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Ben \"Root\" Anderson" Cc: Bug 599958 <599958@bugs.launchpad.net>, qemu-devel@nongnu.org On Tue, Oct 01, 2013 at 11:36:39AM -0500, Ben "Root" Anderson wrote: > Agh, I forgot reply all. > I have to re reply now :) > Seems like something that should be changed, no? It would've saved me > a lot of headache if there was a switch e.g. > -optimize-for=[linux,winxp, > win7,etc] that changed the defaults to be > most accomodating to the specified OS as a guest. > QEMU developers see it to be a management job. Management (libvirt/virt-manager) knows what guest is and what optimal config is. I am not sure they use -no-hpet for windows currently if they do not it should be changed there. > On Tue, Oct 1, 2013 at 11:33 AM, Gleb Natapov wrote: > > On Tue, Oct 01, 2013 at 11:23:07AM -0500, Ben "Root" Anderson wrote: > >> Fair enough in itself, but if HPET is known to have problems with > >> arguably the most popular OS family to use as a guest, why is it > >> enabled by default? > >> > > Arguably :) But QEMU defaults are arguably far from been optimal for any > > guest. > > > >> On Tue, Oct 1, 2013 at 10:56 AM, Gleb Natapov wrote: > >> > On Tue, Oct 01, 2013 at 09:34:06AM -0000, Ben A wrote: > >> >> Apparently this bug's still alive and kicking. > >> >> > >> > And no plans to fix it. Do not use hpet with windows guests this buys > >> > you nothing. > >> > > >> >> There's an obvious clock skew problem on Windows 7; in the Date & Time > >> >> dialog, the clock jumps through seconds visibly too fast. > >> >> > >> >> I also found a case where HPET bugs are causing a real problem: Terraria > >> >> (dedicated server) seems to be relying on (something that relies on) > >> >> HPET, and QEMU doesn't get it right. The result is a goofy and > >> >> aggravating behavior I've nicknamed "Turbo Monsters of Doom" and it > >> >> makes killing anything tougher than a normal zombie basically > >> >> impossible. > >> >> > >> >> -- > >> >> You received this bug notification because you are a member of qemu- > >> >> devel-ml, which is subscribed to QEMU. > >> >> https://bugs.launchpad.net/bugs/599958 > >> >> > >> >> Title: > >> >> Timedrift problems with Win7: hpet missing time drift fixups > >> >> > >> >> Status in QEMU: > >> >> Confirmed > >> >> > >> >> Bug description: > >> >> We've been finding timedrift issues witth Win7 under qemu-kvm on our > >> >> daily testing > >> >> > >> >> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_load FAIL 1 Time drift too large after rest period: 38.63% > >> >> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_reboot FAIL 1 Time drift too large at iteration 1: 17.77 seconds > >> >> kvm.qemu-kvm-git.smp2.Win7.64.timedrift.with_migration FAIL 1 Time drift too large at iteration 2: 3.08 seconds > >> >> > >> >> Steps to reproduce: > >> >> > >> >> timedrift.with_load > >> >> > >> >> 1) Log into a guest. > >> >> 2) Take a time reading from the guest and host. > >> >> 3) Run load on the guest and host. > >> >> 4) Take a second time reading. > >> >> 5) Stop the load and rest for a while. > >> >> 6) Take a third time reading. > >> >> 7) If the drift immediately after load is higher than a user- > >> >> specified value (in %), fail. > >> >> If the drift after the rest period is higher than a user-specified value, > >> >> fail. > >> >> > >> >> timedrift.with_migration > >> >> > >> >> 1) Log into a guest. > >> >> 2) Take a time reading from the guest and host. > >> >> 3) Migrate the guest. > >> >> 4) Take a second time reading. > >> >> 5) If the drift (in seconds) is higher than a user specified value, fail. > >> >> > >> >> timedrift.with_reboot > >> >> > >> >> 1) Log into a guest. > >> >> 2) Take a time reading from the guest and host. > >> >> 3) Reboot the guest. > >> >> 4) Take a second time reading. > >> >> 5) If the drift (in seconds) is higher than a user specified value, fail. > >> >> > >> >> This bug is to register those issues and keep an eye on them. > >> >> > >> >> Attached, some logs from the autotest tests executed on the guest > >> >> > >> >> To manage notifications about this bug go to: > >> >> https://bugs.launchpad.net/qemu/+bug/599958/+subscriptions > >> > > >> > -- > >> > Gleb. > > > > -- > > Gleb. -- Gleb.