Re: rdtscP and xen (and maybe the app-tsc answer I've been looking for)

[Jeremy Fitzhardinge <jeremy@goop.org>]

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