Re: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 21/09/2009 18:56, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

> By constant_tsc I mean that CPUID:0x80000007:EDX:8
> is set.

Well, if it is at least true for 99% of systems, then it might be worth
enabling constant_tsc support by default, and detect TSC divergence at
runtime and disbale dynamically. I think that's what Linux does (i.e., it
has a fallback at runtime if its TSC assumptions turn out to be wrong).

 -- Keir

>  Upstream Linux (2.6.30) now uses the term
> X86_FEATURE_TSC_RELIABLE to indicate that tsc is
> consistent across cores and sockets and
> X86_FEATURE_NONSTOP_TSC to indicate that it
> doesn't stop in deep C-states (which Xen compensates
> for) and X86_FEATURE_CONSTANT_TSC to indicate that
> it stays running across P/T state transitions.
> On Intel systems, CPUID:0x80000007:EDX:8 enables
> all of these feature flags.  (Interestingly, on
> AMD systems, X86_FEATURE_TSC_RELIABLE is *not*
> set by this bit... so my information from AMD is
> not represented in Linux (yet)).  Note also that
> in linux-2.6.30/arch/x86/kernel/cpu/vmware.c, both
> X86_FEATURE_CONSTANT_TSC and X86_FEATURE_TSC_RELIABLE
> get set.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel