From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [RFC] CPUID usage for interaction between Hypervisors and Linux. Date: Wed, 01 Oct 2008 17:39:22 -0700 Message-ID: <48E4183A.7090208@zytor.com> References: <1222881242.9381.17.camel@alok-dev1> <48E3BBC1.2050607@goop.org> <1222894878.9381.63.camel@alok-dev1> <48E3E8DE.1080602@goop.org> <48E3ECD1.30809@codemonkey.ws> <1222904824.7330.83.camel@bodhitayantram.eng.vmware.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Anthony Liguori , Jeremy Fitzhardinge , Alok Kataria , "avi@redhat.com" , Rusty Russell , Gerd Hoffmann , Ingo Molnar , the arch/x86 maintainers , LKML , "Nakajima, Jun" , Daniel Hecht , "virtualization@lists.linux-foundation.org" , "kvm@vger.kernel.org" To: Zachary Amsden Return-path: Received: from terminus.zytor.com ([198.137.202.10]:38047 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752124AbYJBAp3 (ORCPT ); Wed, 1 Oct 2008 20:45:29 -0400 In-Reply-To: <1222904824.7330.83.camel@bodhitayantram.eng.vmware.com> Sender: kvm-owner@vger.kernel.org List-ID: Zachary Amsden wrote: >=20 > Jun, you work at Intel. Can you ask for a new architecturally define= d > MSR that returns the TSC frequency? Not a virtualization specific MS= R. > A real MSR that would exist on physical processors. The TSC started = as > an MSR anyway. There should be another MSR that tells the frequency. > If it's hard to do in hardware, it can be a write-once MSR that gets > initialized by the BIOS. It's really a very simple solution to a ver= y > common problem. Other MSRs are dedicated to bus speed and so on, thi= s > seems remarkably similar. >=20 Ah, if it was only that simple. Transmeta actually did this, but it's=20 not as useful as you think. There are at least three crystals in modern PCs: one at 32.768 kHz (for= =20 the RTC), one at 14.31818 MHz (PIT, PMTMR and HPET), and one at a highe= r=20 frequency (often 200 MHz.) All the main data distribution clocks in the system are derived from th= e=20 third, which is subject to spread-spectrum modulation due to RFI=20 concerns. Therefore, relying on the *nominal* frequency of this clock=20 is vastly incorrect; often by as much as 2%. Spread-spectrum modulatio= n=20 is supposed to vary around zero enough that the spreading averages out,= =20 but the only way to know what the center frequency actually is is to=20 average. Furthermore, this high-frequency clock is generally not=20 calibrated anywhere near as well as the 14 MHz clock; in good designs=20 the 14 MHz is actually a TCXO (temperature compensated crystal=20 oscillator), which is accurate to something like =C2=B12 ppm. -hpa