graphic: 0.980 semantic: 0.978 other: 0.965 instruction: 0.963 assembly: 0.960 mistranslation: 0.958 socket: 0.952 device: 0.951 boot: 0.925 vnc: 0.897 KVM: 0.881 network: 0.799 Timedrift problems with Win7: hpet missing time drift fixups 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 Does adding -no-hpet make a difference? I assume that Win7 is using hpet by default and we currently don't do any time drift mitigation with hpet. I will try that on a separate test job and will let you know about the results. Indeed -no-hpet made the tests pass. It's still uncertain to me whether this flag is supported across several branches of qemu-kvm, if it's supported in all branches I'm going to update the upstream kvm autotest config file. -no-hpet works in every version of qemu/qemu-kvm that has included HPET support. RHEL disables HPET support by default unlike qemu and qemu-kvm. I've updated the bug priority and title to reflect what the issue is. We only support edge triggered interrupts with HPET which seems to be what most OSes use anyway. We could potentially use the reset_irq_delivered/get_irq_delivered APIC functions to implement interrupt catch-up but I think it would be better to try to merge Jan's generic IRQ delivered API first. Sent patch http://patchwork.test.kernel.org/patch/2384/ to autotest and will update the autotest server to reflect that option. Apparently this bug's still alive and kicking. 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. Forgot to add: Reproduced the above behavior in both 1.5.1 and 1.6.0. Adding -no-hpet to commandline removed both problems (full disclosure: this fix wasn't tested in 1.5.1 but I have no reason to believe behavior would be different.) 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? On Tue, Oct 1, 2013 at 10:56 AM, Gleb Natapov