[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49010D1E.8070400@zytor.com>
Date: Thu, 23 Oct 2008 16:47:42 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: akataria@...are.com
CC: Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
LKML <linux-kernel@...r.kernel.org>,
the arch/x86 maintainers <x86@...nel.org>,
Daniel Hecht <dhecht@...are.com>
Subject: Re: [PATCH] Skip tsc synchronization checks if CONSTANT_TSC bit is
set.
Alok Kataria wrote:
>
> I am ok with the CONSTANT_TSC bit check, but if people think that its
> not important to skip this for native, i think adding a new flag to skip
> this should be safe enough.
>
> Ingo, HPA your views on this whole detection and skipping thing ?
>
Okay, first of all, I'm somewhat leery (to put it mildly) of trusting a
CPUID bit to tell me a *system* property, which is that all cores in the
system are synchronized. The CPU designer will know that all the cores
in the *package* are synchronized, but if that extends system-wide is a
property beyond the CPU. Now, if I'm not completely mistaken, in the
case of AMD this bit is actually set by the BIOS via a magic MSR, but
that doesn't mean it can't be wrong.
As far as skipping the check, it makes sense for me in the case of known
virtualization platforms; a CPU feature bit, real or synthetic, is a
very clean way to do that. In general we should centralize CPU
knowledge to arch/x86/kernel/cpu and have the code outside look for
specific feature flags, and that applies to virtualization platforms, too.
-hpa
--
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