From: "H. Peter Anvin" Subject: Re: [PATCH 03 of 36] x86: add memory barriers to wrmsr Date: Wed, 25 Jun 2008 16:42:54 -0700 Message-ID: <4862D7FE.7070507@kernel.org> References: <93c7057b1f4acae501b2.1214367539@localhost> <20080624214441.13202f12@infradead.org> <4862B3E9.50601@goop.org> <20080625153136.2b3b6737@infradead.org> <4862D247.2010709@kernel.org> <4862D6CC.7090205@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4862D6CC.7090205@goop.org> Sender: linux-kernel-owner@vger.kernel.org To: Jeremy Fitzhardinge Cc: Arjan van de Ven , Ingo Molnar , LKML , x86@kernel.org, xen-devel , Stephen Tweedie , Eduardo Habkost , Mark McLoughlin List-Id: xen-devel@lists.xenproject.org Jeremy Fitzhardinge wrote: >> >> Actually, I believe the barrier(); before is actually incorrect, since >> it would affect the wrmsr() register arguments rather than the wrmsr >> instruction itself. > > How so? What kind of failure do think might occur? Some effect on how > the wrmsr arguments are evaluated? > > barrier() is specifically a compiler optimisation barrier, so the > barrier before would prevent the compiler from moving anything logically > before the wrmsr to afterwards. > The barrier() before prevents the compiler from optimizing the access to the arguments (before they go into registers), not the actual wrmsr; this has to do with the ordering of operations around the barrier above. The barrier *after* does what you just describe. > That said, making the wrmsr itself a memory clobber may be simpler > understand with a comment, rather than separate barriers... This should be functionally equivalent to a barrier(); after, and given that this is clearly a point of confusion *already*, I think the memory clobber is better. -hpa