|
|
|
|
|
|
|
|
|
|
xen-devel
[Xen-devel] Re: [PATCH 03 of 36] x86: add memory barriers to wrmsr
To: |
"H. Peter Anvin" <hpa@xxxxxxxxxx> |
Subject: |
[Xen-devel] Re: [PATCH 03 of 36] x86: add memory barriers to wrmsr |
From: |
Jeremy Fitzhardinge <jeremy@xxxxxxxx> |
Date: |
Wed, 25 Jun 2008 16:37:48 -0700 |
Cc: |
Mark McLoughlin <markmc@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Eduardo Habkost <ehabkost@xxxxxxxxxx>, Stephen Tweedie <sct@xxxxxxxxxx>, x86@xxxxxxxxxx, LKML <linux-kernel@xxxxxxxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Arjan van de Ven <arjan@xxxxxxxxxxxxx> |
Delivery-date: |
Wed, 25 Jun 2008 16:38:30 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxx |
In-reply-to: |
<4862D247.2010709@xxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
References: |
<patchbomb.1214367536@localhost> <93c7057b1f4acae501b2.1214367539@localhost> <20080624214441.13202f12@xxxxxxxxxxxxx> <4862B3E9.50601@xxxxxxxx> <20080625153136.2b3b6737@xxxxxxxxxxxxx> <4862D247.2010709@xxxxxxxxxx> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
User-agent: |
Thunderbird 2.0.0.14 (X11/20080501) |
H. Peter Anvin wrote:
Arjan van de Ven wrote:
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.
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.
That said, making the wrmsr itself a memory clobber may be simpler
understand with a comment, rather than separate barriers...
J
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
[Xen-devel] [PATCH 02 of 36] x86: add memory clobber to save/loadsegment, Jeremy Fitzhardinge
[Xen-devel] [PATCH 01 of 36] x86: asm-x86/pgtable.h: fix compiler warning, Jeremy Fitzhardinge
[Xen-devel] [PATCH 04 of 36] x86: remove open-coded save/load segment operations, Jeremy Fitzhardinge
[Xen-devel] [PATCH 09 of 36] x86_64: Use __pgd() on mk_kernel_pgd(), Jeremy Fitzhardinge
[Xen-devel] [PATCH 08 of 36] x86_64: Add gate_offset() and gate_segment() macros, Jeremy Fitzhardinge
[Xen-devel] [PATCH 07 of 36] x86_64: unify early_ioremap, Jeremy Fitzhardinge
[Xen-devel] [PATCH 06 of 36] x86_64: use p??_populate() to attach pages to pagetable, Jeremy Fitzhardinge
[Xen-devel] [PATCH 13 of 36] x86_64: add prototype for x86_64_start_kernel(), Jeremy Fitzhardinge
[Xen-devel] [PATCH 11 of 36] x86: unify mmu_context.h, Jeremy Fitzhardinge
[Xen-devel] [PATCH 10 of 36] x86: unify pgd_index, Jeremy Fitzhardinge
|
|
|
|
|