From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [patch 0/7] force the TSC unreliable by reporting C2 state Date: Wed, 18 Jun 2008 16:42:40 -0500 Message-ID: <48598150.604@codemonkey.ws> References: <20080618164205.108219607@localhost.localdomain> <48596B85.7090008@codemonkey.ws> <20080618204042.GA15981@dmt.cnet> <485977EF.3090002@codemonkey.ws> <20080618212106.GA19602@dmt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Avi Kivity , kvm@vger.kernel.org To: Marcelo Tosatti Return-path: Received: from yw-out-2324.google.com ([74.125.46.30]:56989 "EHLO yw-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754349AbYFRVnN (ORCPT ); Wed, 18 Jun 2008 17:43:13 -0400 Received: by yw-out-2324.google.com with SMTP id 9so258803ywe.1 for ; Wed, 18 Jun 2008 14:43:12 -0700 (PDT) In-Reply-To: <20080618212106.GA19602@dmt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: Marcelo Tosatti wrote: > On Wed, Jun 18, 2008 at 04:02:39PM -0500, Anthony Liguori wrote: > >>>> Have we yet determined why the TSC is so unstable in the first place? >>>> In theory, it should be relatively stable on single-node Intel and >>>> Barcelona chips. >>>> >>>> >>> If the host enters C2/C3, or changes CPU frequency, it becomes >>> unreliable as a clocksource and there's no guarantee the guest will >>> detect that. >>> >>> >> On Intel, the TSC should be fixed-frequency for basically all shipping >> processors supporting VT. Starting with 10h (Barcelona), I believe AMD >> also has a fixed frequency TSC. >> > > But still stops ticking in C2/C3 state, I suppose? > I don't know for sure but the TSC is not tied to the CPU clock so I would be surprised if it did. I think that that would defeat the utility of a fixed-frequency TSC. Regards, Anthony Liguori >>> Also, as mentioned earlier, large systems with clustered APIC have >>> unstable TSC. >>> >>> >> Right, that's why I qualified with single-node. >> >> >>> We _could_ hook this fake-C2-state thing to the host TSC reliability: >>> >>> 1) Hook into Linux's mark_tsc_unstable(). >>> 2) On migration check if the destination host is using the TSC, if not, >>> force a faked-C2-state. >>> >>> Problem with 2) is that not all guests honour the ACPI _CST package >>> notification (which would change C2's latency time from an unusable >>> value to something usable). And now I don't think assuming the _CST >>> notification to work is a good thing (after we found out that for ex. >>> Ubuntu 7.10 kernel ignores it). >>> >>> >> I think that for hosts with a known unstable TSC, we should do something >> like this. But I also think we have a bug with TSC synchronization for >> AMD although I don't at all know what the source of it is. >> > > Chris has some patches around, I don't remember the details either. > > Thanks > >