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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B64E000.3020608@zytor.com>
Date:	Sat, 30 Jan 2010 17:42:24 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Jan Beulich <JBeulich@...ell.com>
CC:	mingo@...e.hu, tglx@...utronix.de,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] x86: enlightenment for ticket spinlocks

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@...ell.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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/