From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andi Kleen Subject: Re: [patch 0/7] force the TSC unreliable by reporting C2 state Date: Fri, 20 Jun 2008 16:07:14 +0200 Message-ID: <87tzfo9p4d.fsf@basil.nowhere.org> References: <20080618164205.108219607@localhost.localdomain> <48596B85.7090008@codemonkey.ws> <20080618204042.GA15981@dmt.cnet> <485977EF.3090002@codemonkey.ws> <20080618212106.GA19602@dmt.cnet> <48598150.604@codemonkey.ws> <20080618224118.GA23236@dmt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Liguori , Avi Kivity , kvm@vger.kernel.org, John Stultz , "Yang, Sheng" To: Marcelo Tosatti Return-path: Received: from smtp-out03.alice-dsl.net ([88.44.63.5]:21227 "EHLO smtp-out03.alice-dsl.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754658AbYFTOIR (ORCPT ); Fri, 20 Jun 2008 10:08:17 -0400 In-Reply-To: <20080618224118.GA23236@dmt.cnet> (Marcelo Tosatti's message of "Wed, 18 Jun 2008 19:41:18 -0300") Sender: kvm-owner@vger.kernel.org List-ID: Marcelo Tosatti writes: > > Well, Linux assumes that TSC stops ticking on C2/C3. It doesn't always and Linux is overly conservative and doesn't know the full rules (and in some cases it's also hard to know because the BIOS hides systems). Also a lot of systems don't have C2/C3. But it still happens occasionally so it has to be handled. Normally we would expect guests to detect this because they have exactly the same problem on real hardware, but at least older Linux didn't always get it correct. But in general the newer kernel already keeps an estimate on how long C2/C3 took (needed for power management) and nobody would stop KVM from just adding that into the TSC offset that is supported by VT. You might still have some drift from that though. -Andi