With the pv-ops based spinlocks reportedly having measurable overhead
on native execution, and with them also not easily fit (at least) fully
virtualized Xen guests, this patch series introduces a replacement
mechanism based on alternative instruction patching, and then uses it
for fully virtualized Xen guests. While coded to be orthogonal to
pv-ops, it really isn't, and it shouldn't be difficult to make pv-ops guests
use this in place of pv-ops spin locks.
The only additional overhead this introduces for native execution is
the writing of the owning CPU in the lock acquire paths. If this is
considered a problem, even that code could be eliminated for native
execution (by further alternative instruction patching).
(1) base implementation
(2) Xen implementation
(3) [optional] eliminate on NOPs in unlock path (introduced in (1))
Signed-off-by: Jan Beulich <[email protected]>
Cc: Jeremy Fitzhardinge <[email protected]>
On 01/29/2010 12:00 AM, Jan Beulich wrote:
> With the pv-ops based spinlocks reportedly having measurable overhead
> on native execution, and with them also not easily fit (at least) fully
> virtualized Xen guests, this patch series introduces a replacement
> mechanism based on alternative instruction patching, and then uses it
> for fully virtualized Xen guests. While coded to be orthogonal to
> pv-ops, it really isn't, and it shouldn't be difficult to make pv-ops guests
> use this in place of pv-ops spin locks.
>
> The only additional overhead this introduces for native execution is
> the writing of the owning CPU in the lock acquire paths. If this is
> considered a problem, even that code could be eliminated for native
> execution (by further alternative instruction patching).
>
> (1) base implementation
> (2) Xen implementation
> (3) [optional] eliminate on NOPs in unlock path (introduced in (1))
>
> Signed-off-by: Jan Beulich <[email protected]>
+ * EBX-EDX: "XenVMMXenVMM" signature, allowing positive identification
+ * of a Xen host.
+ */
+#define XEN_CPUID_SIGNATURE_EBX 0x566e6558 /* "XenV" */
+#define XEN_CPUID_SIGNATURE_ECX 0x65584d4d /* "MMXe" */
+#define XEN_CPUID_SIGNATURE_EDX 0x4d4d566e /* "nVMM" */
I hope you know this spells "MMXenVMMXenV". The ordering is ecx-edx-ebx
(register numbers 1, 2, 3).
[Still working through the actual contents of the patchset... just a
nitpick.]
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 01/30/2010 05:42 PM, H. Peter Anvin wrote:
>
> + * EBX-EDX: "XenVMMXenVMM" signature, allowing positive identification
> + * of a Xen host.
> + */
> +#define XEN_CPUID_SIGNATURE_EBX 0x566e6558 /* "XenV" */
> +#define XEN_CPUID_SIGNATURE_ECX 0x65584d4d /* "MMXe" */
> +#define XEN_CPUID_SIGNATURE_EDX 0x4d4d566e /* "nVMM" */
>
> I hope you know this spells "MMXenVMMXenV". The ordering is ecx-edx-ebx
> (register numbers 1, 2, 3).
>
... and of course I got it wrong, too. It spells "XenVnVMMMMXe".
The proper order is ebx-edx-ecx, in *reverse* numerical order.
Confusing, yes.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
>>> "H. Peter Anvin" 01/31/10 2:42 AM >>>
>+ * EBX-EDX: "XenVMMXenVMM" signature, allowing positive identification
>+ * of a Xen host.
>+ */
>+#define XEN_CPUID_SIGNATURE_EBX 0x566e6558 /* "XenV" */
>+#define XEN_CPUID_SIGNATURE_ECX 0x65584d4d /* "MMXe" */
>+#define XEN_CPUID_SIGNATURE_EDX 0x4d4d566e /* "nVMM" */
>
>I hope you know this spells "MMXenVMMXenV". The ordering is ecx-edx-ebx
>(register numbers 1, 2, 3).
According to the documentation I have, the ordering is EBX-EDX-ECX,
so indeed the spelling would seem broken, but since this is an interface
header taken directly from Xen, it's got to be (and it works) that way.
Odd.
Jan
On 01/31/2010 10:02 AM, Jan Beulich wrote:
>>>> "H. Peter Anvin" 01/31/10 2:42 AM >>>
>> + * EBX-EDX: "XenVMMXenVMM" signature, allowing positive identification
>> + * of a Xen host.
>> + */
>> +#define XEN_CPUID_SIGNATURE_EBX 0x566e6558 /* "XenV" */
>> +#define XEN_CPUID_SIGNATURE_ECX 0x65584d4d /* "MMXe" */
>> +#define XEN_CPUID_SIGNATURE_EDX 0x4d4d566e /* "nVMM" */
>>
>> I hope you know this spells "MMXenVMMXenV". The ordering is ecx-edx-ebx
>> (register numbers 1, 2, 3).
>
> According to the documentation I have, the ordering is EBX-EDX-ECX,
> so indeed the spelling would seem broken, but since this is an interface
> header taken directly from Xen, it's got to be (and it works) that way.
> Odd.
>
It's probably a bug that's now cast in stone. That happends. I just
had to be picky. (And yes, it's ebx-edx-ecx; see my second email.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
>>> "H. Peter Anvin" <[email protected]> 31.01.10 19:43 >>>
>On 01/31/2010 10:02 AM, Jan Beulich wrote:
>>>>> "H. Peter Anvin" 01/31/10 2:42 AM >>>
>>> + * EBX-EDX: "XenVMMXenVMM" signature, allowing positive identification
>>> + * of a Xen host.
>>> + */
>>> +#define XEN_CPUID_SIGNATURE_EBX 0x566e6558 /* "XenV" */
>>> +#define XEN_CPUID_SIGNATURE_ECX 0x65584d4d /* "MMXe" */
>>> +#define XEN_CPUID_SIGNATURE_EDX 0x4d4d566e /* "nVMM" */
>>>
>>> I hope you know this spells "MMXenVMMXenV". The ordering is ecx-edx-ebx
>>> (register numbers 1, 2, 3).
>>
>> According to the documentation I have, the ordering is EBX-EDX-ECX,
>> so indeed the spelling would seem broken, but since this is an interface
>> header taken directly from Xen, it's got to be (and it works) that way.
>> Odd.
>>
>
>It's probably a bug that's now cast in stone. That happends. I just
>had to be picky. (And yes, it's ebx-edx-ecx; see my second email.)
The "good" thing is that this is not on leaf 0, but on leaf 0x4000??00,
i.e. "normal" code would never display this garbled string.
Jan
On 01/31/2010 11:56 PM, Jan Beulich wrote:
>>
>> It's probably a bug that's now cast in stone. That happends. I just
>> had to be picky. (And yes, it's ebx-edx-ecx; see my second email.)
>
> The "good" thing is that this is not on leaf 0, but on leaf 0x4000??00,
> i.e. "normal" code would never display this garbled string.
>
Well, yes, but the format of ID leaves is the same between groups.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.