Re: [PATCH 0/3] x86: enlightenment for ticket spinlocks

["H. Peter Anvin" <hpa@zytor.com>]

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 <jbeulich@novell.com>

+ * 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.