[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [PATCH 2/5] x86/pvclock: no need to use strong read barriers in pvclock_get_time_values



The time values are guaranteed to be only updated by the pcpu that the
vcpu is currently running on (preempting the guest), so there's never
any risk of cross-pcpu races.  Therefore, we only need a barrier to
prevent compiler reordering.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@xxxxxxxxxx>
---
 arch/x86/kernel/pvclock.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/pvclock.c b/arch/x86/kernel/pvclock.c
index 963f349..5ecce7f 100644
--- a/arch/x86/kernel/pvclock.c
+++ b/arch/x86/kernel/pvclock.c
@@ -86,12 +86,12 @@ static unsigned pvclock_get_time_values(struct 
pvclock_shadow_time *dst,
 {
        do {
                dst->version = src->version;
-               rmb();          /* fetch version before data */
+               barrier();              /* fetch version before data */
                dst->tsc_timestamp     = src->tsc_timestamp;
                dst->system_timestamp  = src->system_time;
                dst->tsc_to_nsec_mul   = src->tsc_to_system_mul;
                dst->tsc_shift         = src->tsc_shift;
-               rmb();          /* test version after fetching data */
+               barrier();              /* test version after fetching data */
        } while ((src->version & 1) || (dst->version != src->version));
 
        return dst->version;
-- 
1.6.2.5


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.