From mboxrd@z Thu Jan  1 00:00:00 1970
From: Zachary Amsden <zamsden@redhat.com>
Subject: Bug in KVM clock backwards compensation
Date: Wed, 27 Apr 2011 23:59:57 -0700
Message-ID: <4DB9106D.6040203@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
To: kvm <kvm@vger.kernel.org>, Jan Kiszka <jan.kiszka@web.de>,
	Joerg Roedel <joerg.roedel@amd.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:21005 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1753405Ab1D1HAA (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 28 Apr 2011 03:00:00 -0400
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

So I've been going over the new code changes to the TSC related code and 
I don't like one particular set of changes.  In particular, here:

         kvm_x86_ops->vcpu_load(vcpu, cpu);
         if (unlikely(vcpu->cpu != cpu) || check_tsc_unstable()) {
                 /* Make sure TSC doesn't go backwards */
                 s64 tsc_delta;
                 u64 tsc;

                 kvm_get_msr(vcpu, MSR_IA32_TSC, &tsc);
                 tsc_delta = !vcpu->arch.last_guest_tsc ? 0 :
                              tsc - vcpu->arch.last_guest_tsc;

                 if (tsc_delta < 0)
                         mark_tsc_unstable("KVM discovered backwards TSC");
                 if (check_tsc_unstable()) {
                         kvm_x86_ops->adjust_tsc_offset(vcpu, -tsc_delta);
                         vcpu->arch.tsc_catchup = 1;
                 }


The point of this code fragment is to test the host clock to see if it 
is stable, because we may have just come back from an idle phase which 
stopped the TSC, switched CPUs, or come back from a deep sleep state 
which reset the host TSC.

However, the above code is fetching the guest TSC instead of the host 
TSC, which isn't the way it is supposed to work.

I saw a patch floating around that touched this code recently, but I 
think there's a definite issue here that needs addressing.

Zach