RE: [Xen-devel] [RFC] [PATCH] use "reliable" tsc properly when available, but verify

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> 
> Given that TSC is now emulated, who cares what the underlying 
> CPUs say about
> TSC reliability. Xen emulates the TSC with its own system 
> time, and even
> explicitly checks that the returned TSC value is 
> monotonically increasing.
> So TSC is alweays 'reliable' for guests, regardless of host 
> TSC behaviour.
> So on this count, too, the patch is a reject.

Ouch.  I thought RFC was "request for comment", not
"request for castration" ;-) ;-)

Let me clarify my intent:

I remain very much committed to emulated-tsc
("correctness") as the default for unmodified apps
even if there is a significant loss of performance.
Call this Phase I

BUT I am continuing to work on how an "aware" app
(or an "aware" OS) in a constrained environment can
obtain both correctness AND performance.  Call this
Phase II.  Pvrdtscp and Xiantao's scaling are
different approaches to Phase II, for pvm and
hvm respectively. Vsyscall+pvclock also if a PV
OS can be made aware whether tsc_native is enabled
or not.

This proposed patch is really only important for Phase
II, but given all the confusion around whether tsc is
reliable/safe/constant/nonstop on various machines,
I think it might be good to get code into Xen --
sooner rather than later -- that "measures" this
so we can confirm if the promises made by processor
and system vendors are (or are not) being delivered.

Does that make more sense?

Thanks,
Dan

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