This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] Prevent incorrect optimization of read_crx()

To: "Joseph Cihula" <joseph.cihula@xxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Prevent incorrect optimization of read_crx()
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Tue, 11 Sep 2007 07:52:04 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 10 Sep 2007 23:51:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D936D925018D154694D8A362EEB08920025E57F5@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: <D936D925018D154694D8A362EEB08920025E57F5@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Wouldn't you need to put __volatile__ in write_crX(), too? And does it really
make sense to put it in read_cr2()? Jan

>>> "Cihula, Joseph" <joseph.cihula@xxxxxxxxx> 10.09.07 23:55 >>>
This patch prevents the compiler from optimizing multiple read_crx()
calls when there might be an intervening write_crx().  E.g.:
        write_cr0(read_cr0() | X86_CR0_PE);
        if ( read_cr0() & X86_CR0_PE )  <- could get old value (w/o PE

This was actually seen to happen in the sboot code that copied this
header from Xen.  Without the volatile attribute, the compiler simply
cached the result of the first read and returned it for the second.
This was made even more problematic, in this particular case, because
the two read's were in separate static fns that the compiler also
coalesced into a single function before it optimized it.


# HG changeset patch
# User Joseph Cihula <joseph.cihula@xxxxxxxxx>
# Date 1189460837 25200
# Node ID 0e8e662becc240b424682a78ec9efbeaf6e84745
# Parent  9071521d48646d247efafcf230ea0a4a2b6f0efa
Prevents incorrect optimization of read_crx() calls with an intervening

Signed-off-by:  Joseph Cihula <joseph.cihula@xxxxxxxxx>

diff -r 9071521d4864 -r 0e8e662becc2 xen/include/asm-x86/processor.h
--- a/xen/include/asm-x86/processor.h   Fri Sep 07 11:39:10 2007 +0100
+++ b/xen/include/asm-x86/processor.h   Mon Sep 10 14:47:17 2007 -0700
@@ -281,7 +281,7 @@ static inline unsigned long read_cr0(voi
 static inline unsigned long read_cr0(void)
     unsigned long __cr0;
-    __asm__("mov %%cr0,%0\n\t" :"=r" (__cr0));
+    __asm__ __volatile__("mov %%cr0,%0\n\t" :"=r" (__cr0));
     return __cr0;
@@ -293,14 +293,14 @@ static inline unsigned long read_cr2(voi
 static inline unsigned long read_cr2(void)
     unsigned long __cr2;
-    __asm__("mov %%cr2,%0\n\t" :"=r" (__cr2));
+    __asm__ __volatile__("mov %%cr2,%0\n\t" :"=r" (__cr2));
     return __cr2;
 static inline unsigned long read_cr4(void)
     unsigned long __cr4;
-    __asm__("mov %%cr4,%0\n\t" :"=r" (__cr4));
+    __asm__ __volatile__("mov %%cr4,%0\n\t" :"=r" (__cr4));
     return __cr4;

Xen-devel mailing list