Date: Wed, 25 Jun 2008 15:31:36 -0700
From: Arjan van de Ven <arjan@infradead.org>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
       x86@kernel.org, xen-devel <xen-devel@lists.xensource.com>,
       Stephen Tweedie <sct@redhat.com>, Eduardo Habkost <ehabkost@redhat.com>,
       Mark McLoughlin <markmc@redhat.com>
Subject: Re: [PATCH 03 of 36] x86: add memory barriers to wrmsr
Message-ID: <20080625153136.2b3b6737@infradead.org>
In-Reply-To: <4862B3E9.50601@goop.org>
References: <patchbomb.1214367536@localhost>
	<93c7057b1f4acae501b2.1214367539@localhost>
	<20080624214441.13202f12@infradead.org>
	<4862B3E9.50601@goop.org>
Organization: Intel
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1124
Lines: 36

On Wed, 25 Jun 2008 14:08:57 -0700
Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Arjan van de Ven wrote:
> > it's more readable for several of these cases to stick a barrier();
> > in front and after it to be honest; that makes it more explicit that
> > these are deliberate compiler barriers rather than "actual" memory
> > access...
> >
> >   
> 
> I suppose, though I would be inclined to put the barriers in the
> wrmsr macro itself to act as documentation. 


yeah I meant like this:

static inline void native_write_msr(unsigned int msr,
 				    unsigned low, unsigned high)
{
	barrier();
	asm volatile("wrmsr" : : "c" (msr), "a"(low), "d" (high));
	barrier();
}

or in the same in the thing that calls this.

-- 
If you want to reach me at my work email, use arjan@linux.intel.com
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/