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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> Are vendors really making guarantees about a flag
> which they do not directly provide?

Sorry, I was overly terse and had lost some of my
context due to a machine crash over the weekend.

By constant_tsc I mean that CPUID:0x80000007:EDX:8
is set.  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.

Some of this is explained nicely here:
http://lkml.indiana.edu/hypermail/linux/kernel/0811.2/00837.html
https://lists.ubuntu.com/archives/kernel-team/2008-October/004279.html
https://lists.ubuntu.com/archives/kernel-team/2008-October/004282.html

(This last one also re-enforces my answer to Jeremy as
to why users of the proposed pvrdtscp interface would
still need to post-filter rdtscp values to guarantee no
time-going-backwards problems.)

> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Monday, September 21, 2009 11:02 AM
> To: Dan Magenheimer; Jan Beulich
> Cc: JeremyFitzhardinge; Xen-Devel (E-mail); Kurt Hackel; Langsdorf,
> Mark; Nakajima, Jun; Alex Williamson
> Subject: Re: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer
> I've been looking for)
> 
> 
> On 21/09/2009 17:55, "Dan Magenheimer" 
> <dan.magenheimer@xxxxxxxxxx> wrote:
> 
> > Both Intel and AMD have confirmed that constant_tsc means
> > that TSC is consistent across all cores and even across
> > multiple sockets; and at least one major system vendor (HP)
> > with multi-enclosure "big iron" AMD-based NUMA systems has
> > confirmed that TSC is consistent across all nodes.   So
> > by applying the Xen rendezvous-sync algorithm (that writes
> > tsc every second) on such machines, Xen has actually been
> > creating a tsc-sync problem, not alleviating one!
> 
> Constant_tsc is not even directly a hardware flag. It's a 
> synthetic value
> that Linux derives for itself and we inherited. Are vendors 
> really making
> guarantees about a flag which they do not directly provide?
> 
>  -- Keir
> 
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

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