RE: [Xen-devel] write_tsc in a PV domain?

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> I think this is getting a bit repetitive.

True, and we are going down some unfortunate
ratholes.  So let's see if we can focus on
the core of the disagreement.

> Apps are free to try and use the tsc in any way they
> feel like, but it has never had any
> GUARANTEED [djm's emphasis] properties.

I think this is the key difference of opinion which
must be resolved.  If what you say is true, your
other positions make sense.  If it is false,
they make much less sense.  (And unfortunately
it is not a black and white issue.)

There ARE guaranteed properties specified by
the Intel SDM for any _single_ processor,
namely that rdtsc is "guaranteed to return
a monotonically increasing unique value whenever
executed, except for 64-bit counter wraparound.
Intel guarantees that the time-stamp counter
will not wrap-around within 10 years after being
reset."  Both uses of the word "guarantee"
are quoted from the Intel SDM.

What is NOT guaranteed, but is widely and
incorrectly assumed to be implied and has
gotten us into this mess, is that
the same properties applies across multiple
processors.  And there are notable examples
of systems where the properties do NOT apply.
So it is true that an app that
does not know conclusively that certain threads
are running on certain processors cannot
always safely use rdtsc to obtain the
single-processor-guaranteed results.

BUT some software systems (including VMware) do
provide this guarantee across multiple processors.
And recent families of both Intel and AMD
multi-core have advanced to the point where
the properties apply across all cores, so
on the vast majority (but admittedly not all)
of future physical systems, apps can and will
use rdtsc and expect the properties to apply
(whether guaranteed or not).

So in your opinion, some systems are broken
so Xen should assume all future systems are
broken.  In my opinion, the problem is being
fixed in hardware and has always been fixed
in VMware, so Xen should look to the future
not the past.

Does that sound like a good summary of this
disagreement?

P.S. Summarizing the broader discussion on a
new thread.

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