[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] rdtscP and xen (and maybe the app-tsc answer I've been looking for)
On 09/22/09 08:16, Jan Beulich wrote: >> Pardon my x86 ignorance again: If we define a userland rdmsr, >> it could overwrite more than just EDX:EAX. If it overwrites >> all registers that can safely be changed by the calling >> convention, which registers (how many bits) can it "return"? >> I suspect this isn't enough for 32-bit guests, but maybe >> it is for 64-bit guests? >> > On 32-bit you have 3 registers if you don't want to touch callee > saved ones. > On 64-bit you have 7 of them (considering the differences between > Unix and Windows calling conventions, and hoping there's no third > set in use somewhere). > It doesn't really matter what registers you choose (but 3 is not enough; you need around 200 bits of state for the pvclock params). This special rdtsc (presumably done in the same way as the Xen cpuid, with the XEN_EMULATE_PREFIX) and would need to be carefully emitted in an inline asm, which can do whatever other fixups are required save registers and move values into the right place (gcc inline asm will pretty much automate this). But I think doing this direct from usermode is a bad idea; interactions with Xen should be mediated by the kernel, even if just via a /dev/xen/pvclock driver. J _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |