From mboxrd@z Thu Jan  1 00:00:00 1970
From: Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: kvm-unit-test failures
Date: Wed, 03 Sep 2014 19:52:28 +0200
Message-ID: <5407555C.2010804@redhat.com>
References: <53FDDD3F.8050102@redhat.com> <1409150751-22763-1-git-send-email-chris.j.arges@canonical.com> <53FDF09F.4060007@redhat.com> <53FE4C7E.90201@canonical.com> <1018860798.37183509.1409177149937.JavaMail.zimbra@redhat.com> <5400BA22.9080704@canonical.com> <5400EB01.1080106@canonical.com> <540347AD.20308@redhat.com> <54062146.9040609@canonical.com> <54072CBF.7080108@redhat.com> <5407407F.3060500@canonical.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Cc: kvm@vger.kernel.org
To: Chris J Arges <chris.j.arges@canonical.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mail-wg0-f49.google.com ([74.125.82.49]:40226 "EHLO
	mail-wg0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751042AbaICRwe (ORCPT <rfc822;kvm@vger.kernel.org>);
	Wed, 3 Sep 2014 13:52:34 -0400
Received: by mail-wg0-f49.google.com with SMTP id y10so8868465wgg.20
        for <kvm@vger.kernel.org>; Wed, 03 Sep 2014 10:52:32 -0700 (PDT)
In-Reply-To: <5407407F.3060500@canonical.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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