[Xen-devel] Guest TSC and Xen (Intel and AMD feedback please)

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

Various versions of Linux under various circumstances select
TSC as the primary clocksource for the kernel.  This is
especially true for uniprocessor kernels, but also in some
cases for multiprocessor kernels.  In most cases, this
is because a processor bit (tsc_invariant? constant_tsc?)
is passed through directly from the hardware via Xen and
tested by the hvm guest and the result implies that the
TSC is "stable".

I'd like to propose that, for a Xen hvm guest, TSC should
NEVER be considered stable.  For at least these reasons:

1) Often this test is done once at guest boot; if the guest
   migrates to another machine without the bit set, time
   will be erratic.
2) I *think* that in some cases even within the same system,
   TSC values will skew somewhat.  Since a uniprocessor guest
   will often be rescheduled to a different pcpu by Xen,
   the underlying tsc may appear erratic.

Comments (especially from Intel and AMD)?

If agreed, could Intel and AMD provide patches so that hvm
reads of the bits return "false"?  Or will this cause other
problems?

Another alternative would be to trap all rdtsc's and emulate
them but this probably will not be easy and may have
significant performance implications.  But perhaps it should
be an option?

Dan

===================================
Thanks... for the memory
I really could use more / My throughput's on the floor
The balloon is flat / My swap disk's fat / I've OOM's in store
Overcommitted so much
(with apologies to the late great Bob Hope)

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