From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [KVM timekeeping 10/35] Fix deep C-state TSC desynchronization Date: Tue, 14 Sep 2010 11:10:27 +0200 Message-ID: <4C8F3C03.50306@siemens.com> References: <1282291669-25709-1-git-send-email-zamsden@redhat.com> <1282291669-25709-11-git-send-email-zamsden@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, Avi Kivity , Marcelo Tosatti , Glauber Costa , Thomas Gleixner , John Stultz , linux-kernel@vger.kernel.org To: Zachary Amsden Return-path: Received: from david.siemens.de ([192.35.17.14]:23720 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751085Ab0INJKt (ORCPT ); Tue, 14 Sep 2010 05:10:49 -0400 In-Reply-To: <1282291669-25709-11-git-send-email-zamsden@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Am 20.08.2010 10:07, Zachary Amsden wrote: > When CPUs with unstable TSCs enter deep C-state, TSC may stop > running. This causes us to require resynchronization. Since > we can't tell when this may potentially happen, we assume the > worst by forcing re-compensation for it at every point the VCPU > task is descheduled. > > Signed-off-by: Zachary Amsden > --- > arch/x86/kvm/x86.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 7fc4a55..52b6c21 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -1866,7 +1866,7 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu) > } > > kvm_x86_ops->vcpu_load(vcpu, cpu); > - if (unlikely(vcpu->cpu != cpu)) { > + if (unlikely(vcpu->cpu != cpu) || check_tsc_unstable()) { > /* Make sure TSC doesn't go backwards */ > s64 tsc_delta = !vcpu->arch.last_host_tsc ? 0 : > native_read_tsc() - vcpu->arch.last_host_tsc; For yet unknown reason, this commit breaks Linux guests here if they are started with only a single VCPU. They hang during boot, obviously no longer receiving interrupts. I'm using kvm-kmod against a 2.6.34 host kernel, so this may be a side effect of the wrapping, though I cannot imagine how. Anyone any ideas? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux