Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754477Ab0HQFvx (ORCPT ); Tue, 17 Aug 2010 01:51:53 -0400 Received: from smtp-outbound-2.vmware.com ([65.115.85.73]:12730 "EHLO smtp-outbound-2.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750976Ab0HQFvw (ORCPT ); Tue, 17 Aug 2010 01:51:52 -0400 Subject: Re: [Patch] Skip cpu_calibrate for kernel running under hypervisors. From: Alok Kataria Reply-To: akataria@vmware.com To: "H. Peter Anvin" Cc: the arch/x86 maintainers , Greg KH , "greg@kroah.com" , "ksrinivasan@novell.com" , LKML In-Reply-To: <4C69D02F.6090601@zytor.com> References: <1281986754.23253.32.camel@ank32.eng.vmware.com> <4C69D02F.6090601@zytor.com> Content-Type: text/plain Organization: VMware INC. Date: Mon, 16 Aug 2010 22:51:51 -0700 Message-Id: <1282024311.20786.2.camel@ank32.eng.vmware.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-8.el5_2.3) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2390 Lines: 60 Thanks for taking a look. On Mon, 2010-08-16 at 16:56 -0700, H. Peter Anvin wrote: > On 08/16/2010 12:25 PM, Alok Kataria wrote: > > Hi, > > > > This is a trivial change to fix the cpu_khz value returned when running > > on a virtualized environment. We have seen instances when the cpu_khz > > value is off by couple of MHz's when running on VMware's platform on AMD > > hardware. > > > > -- > > Since the TSC frequency read from hypervisor is accurate for the guest, and > > since the hypervisor will always clock the vcpu at the TSC frequency, there is > > no need to calibrate it again. To avoid any calibration errors through > > calibrate_cpu this patch skips calling calibrate_cpu for kernel running > > under hypervisors. > > > > I'm somewhat reluctant to take this one, since it assumes all the > hypervisors act the same. This seems rather inherently wrong. In fact, > the whole statement is fishy as heck... instead of being dependent on > AMD and so on, The check about being on AMD is something that was already there. > this should either be a function pointer or a CPU > (mis)feature bit. In any case, I agree that my previous patch did assume all hypervisors to be same, which might be wrong. How about using the X86_FEATURE_TSC_RELIABLE bit for this too ? i.e. Skip cpu_calibrate call if TSC_RELIABLE bit is set. As of now that bit is set for vmware only. Something like the below. Signed-off-by: Alok N Kataria Cc: H. Peter Anvin Index: linux-x86-tree.git/arch/x86/kernel/tsc.c =================================================================== --- linux-x86-tree.git.orig/arch/x86/kernel/tsc.c 2010-08-03 12:21:20.000000000 -0700 +++ linux-x86-tree.git/arch/x86/kernel/tsc.c 2010-08-16 21:59:32.000000000 -0700 @@ -927,7 +927,8 @@ void __init tsc_init(void) } if (cpu_has(&boot_cpu_data, X86_FEATURE_CONSTANT_TSC) && - (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)) + (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) && + !(cpu_has(&boot_cpu_data, X86_FEATURE_TSC_RELIABLE))) cpu_khz = calibrate_cpu(); printk("Detected %lu.%03lu MHz processor.\n", -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/