lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1282024311.20786.2.camel@ank32.eng.vmware.com>
Date:	Mon, 16 Aug 2010 22:51:51 -0700
From:	Alok Kataria <akataria@...are.com>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	the arch/x86 maintainers <x86@...nel.org>,
	Greg KH <gregkh@...e.de>, "greg@...ah.com" <greg@...ah.com>,
	"ksrinivasan@...ell.com" <ksrinivasan@...ell.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Patch] Skip cpu_calibrate for kernel running under
	hypervisors.

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 <akataria@...are.com>
Cc: H. Peter Anvin <hpa@...or.com>

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ