From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zachary Amsden Subject: Re: Bug in KVM clock backwards compensation Date: Thu, 28 Apr 2011 12:06:53 -0700 Message-ID: <4DB9BACD.2090609@redhat.com> References: <4DB9106D.6040203@redhat.com> <4DB911D9.3010409@web.de> <20110428072209.GH20365@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , kvm To: "Roedel, Joerg" Return-path: Received: from mx1.redhat.com ([209.132.183.28]:17836 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755369Ab1D1TG4 (ORCPT ); Thu, 28 Apr 2011 15:06:56 -0400 In-Reply-To: <20110428072209.GH20365@amd.com> Sender: kvm-owner@vger.kernel.org List-ID: On 04/28/2011 12:22 AM, Roedel, Joerg wrote: > On Thu, Apr 28, 2011 at 03:06:01AM -0400, Jan Kiszka wrote: > >> And /me still wonders (like I did when this first popped up) if the >> proper place of determining TSC stability really have to be KVM. >> >> If the Linux core fails to detect some instability and KVM has to jump >> in, shouldn't we better improve the core's detection abilities and make >> use of them in KVM? Conceptually this looks like we are currently just >> working around a core deficit in KVM. >> > Yes, good question. Has this ever triggered on a real machine (not > counting the suspend/resume issue in)? > Yes... some platforms don't go haywire until you start using power mangement, TSC is stable before that, but not afterwards, and depending on the version of the kernel, KVM might detect this before the kernel does. Honestly, the code is obsolete, but still useful for those who build KVM as an external module on older kernels using the kvm-kmod system. Zach