Il 03/09/2014 18:23, Chris J Arges ha scritto: > $ uptime > 16:18:31 up 53 min, 1 user, load average: 1.16, 0.39, 0.17 > > $ grep -m1 model.name /proc/cpuinfo > model name : Intel(R) Xeon(R) CPU E5-2697 v3 @ 2.60GHz > > Here is the output of the command: > qemu-system-x86_64 -enable-kvm -device pc-testdev -device > isa-debug-exit,iobase=0xf4,iosize=0x4 -display none -serial stdio > -device pci-testdev -kernel x86/kvmclock_test.flat -smp 2 --append > 10000000 1409761075 > enabling apic > enabling apic > kvm-clock: cpu 0, msr 0x:44e520 > kvm-clock: cpu 0, msr 0x:44e520 > Wallclock test, threshold 5 > Seconds get from host: 1409761075 > Seconds get from kvmclock: 1409757927 > Offset: -3148 > offset too large! > Wallclock test, threshold 5 > Seconds get from host: 1409761075 > Seconds get from kvmclock: 1409757927 > Offset: -3148 > offset too large! > Check the stability of raw cycle ... > Worst warp -3147762665310 I'm not sure about the reason for the warp, but indeed the offset and uptime match (I'll check them against the trace tomorrow) so it's "just" that the VM's TSC base is not taken into account correctly. Can you gather another trace with the problematic patch reverted? Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html