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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Xen doesn't appear to support the rdtscp instruction.
Should it?  (And specifically I'm wondering whether
it should be emulated whenever rdtsc is emulated
but see below for another intriguing possibility.)

Rdtscp is unprivileged and we have apps that are using it
on bare metal, after validating that the CPU supports it.
The instruction is available on most (all?) recent AMD
CPUs and Intel's Nehalem supports it.

For an OS to support rdtscp properly, the OS must (once at boot)
wrmsr a different value for each cpu to a "TSC_AUX" register
and this register is read along with the TSC when the rdtscp
instruction is executed.  This allows an app to determine
if two consecutive rdtsc's are (or are not) executed on the
same CPU.

It appears that all recent RHEL kernels write to TSC_AUX if
the CPU supports rdtscp.  I'm told Windows 2008 notably does
not.  Don't know about SLES or other Windoze.

Its not clear to me if/how rdtscp can/should be virtualized.
To do it properly, the value written to the TSC_AUX msr
would become part of the vcpu's state, and would need to
be changed whenever a vcpu->pcpu mapping changes.  To meet
only the current use model of the instruction, Xen could write
TSC_AUX for each pcpu on Xen boot and always ignore guest
OS writes to TSC_AUX.  (This assumes that no OS ever reads
TSC_AUX and attempts to match it with the value that it
thought it wrote to TSC_AUX; and assumes that 

One solution is for Xen to deny the existence of rdtscp even
when Xen is running on hardware that supports it.  Is that
exactly what is happening?

Now thinking creatively, could TSC_AUX be used similar
to the pvclock version number... Xen bumps it whenever a
migration occurs which would prompt an app to go out
and reread new values for scaling and offset (possibly
via specially-handled-by-Xen usermode rdmsr)?  Hmmm...
I think it might be the answer I've been looking for!
(Go ahead, shoot me down :-)

Dan

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