RE: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)

["Jan Beulich" <JBeulich@xxxxxxxxxx>]

>>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 01.09.09 18:41 >>>
>> >>> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> 01.09.09 17:56 >>>
>> >Can you think of any trick (that doesn't require the cost of a
>> >trap/hypercall) to allow an app to determine what pcpu
>> >it is running on?
>> 
>> Just like what is being used to allow apps to get the CPU 
>> number on native
>> kernels (or the vCPU one on Xen-ified ones): Have a GDT entry 
>> the limit of
>> which is the number you want, and have the app use the lsl 
>> instruction to
>> get at it.
>
>Can you explain more?  Will this work for a userland
>process to get its current pcpu (not vcpu)?

Sure, if the descriptor's DPL is set to 3.

>> I am, however, always a little bit concerned when it comes to exposing
>> information that shouldn't really be exposed, due to the 
>> possibility of
>> overlooking potential misuses. In the specific case here, I 
>> can't see at all
>> why you'd the pCPU number exposed
>
>There is one pvclock "struct" for each pcpu.  We want
>an app to "see" the right one.  If that's not possible,
>we want the app to see the whole array of them and be
>able to properly index into the array.

These pvclock structs should be per vCPU, shouldn't they? The
hypervisor ensures that the per-vCPU structure reflects the proper
state on the pCPU that vCPU is currently running on.

>> after all the kernel can do what
>> you want apps to do without having that information.
>
>In the current Linux 2.6.30 implementation of pvclock
>it can do it, but it can't do it fast.  In versions
>of the kernel prior to 2.2.28(?), it can't do it at
>all, correct?

I don't think it ever uses a pCPU number. If it does, just point me to
where this is happening.

Jan


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