[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)
>>> 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
I don't think it ever uses a pCPU number. If it does, just point me to
where this is happening.
Xen-devel mailing list