[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |