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

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 22.09.09 17:00 >>>
>> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 22.09.09 01:29 >>>
>> >Yes, I neglected an important pre-condition.  ASSUME the first
>> >rdtscp on pcpu-A gets a version mismatch so that it must fetch
>> >the parameters again.  Then: the vcpu switches pcpu TWICE
>> >from pcpu-A to pcpu-B and back to pcpu-A and does rdtscp
>> >each time on pcpu-A but reads one or more pvclock parameters
>> >(that are too big to be encoded in TSC_AUX) on pcpu-B.
>> 
>> This fundamentally depends on how the pvclock parameters are being
>> read: While app-accessible MSRs inherently require each of 
>> the necessary
>> RDMSRs to be executed on the correct {p,v}CPU (unless you encode the
>> CPU number in the RDMSR input), an app accessible shared memory region
>> wouldn't have that property.
>
>Hmmm...  I think a shared memory region still does have that property.
>To avoid any possibility of a race, there must be a way to atomically
>fetch the full set of values:
>
>{ tsc, tsc_aux, pvclock parameters }.
>
>(How many bits total in pvclock parameters?)

Of course the expectation would be that the in-memory values are also
tagged with a version.

>Jeremy's proposal of a userland hypercall ("get_new_pvclock_info")
>can do that, but I don't see how a shared memory region can.
>But a userland hypercall that writes to userland memory seems
>risky.  An app can mmap memory, if it fails to do so (either
>accidentally or maliciously), bad things can happen, correct?

No, I don't think that's more risky than writing to kernel memory - Xen
would get a page fault, and skip the write (and return -EFAULT).

>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).

Jan


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