On Thu, Nov 01, 2012 at 05:49:51PM +0400, Glauber Costa wrote:
> On 11/01/2012 03:48 PM, Gleb Natapov wrote:
> > On Wed, Oct 31, 2012 at 08:46:58PM -0200, Marcelo Tosatti wrote:
> >> Originally from Jeremy Fitzhardinge.
> >>
> >> pvclock_get_time_values, which contains the memory barriers
> >> will be removed by next patch.
> >>
> >> Signed-off-by: Marcelo Tosatti <[email protected]>
> >>
> >> Index: vsyscall/arch/x86/kernel/pvclock.c
> >> ===================================================================
> >> --- vsyscall.orig/arch/x86/kernel/pvclock.c
> >> +++ vsyscall/arch/x86/kernel/pvclock.c
> >> @@ -97,10 +97,10 @@ cycle_t pvclock_clocksource_read(struct 
> >>  
> >>    do {
> >>            version = pvclock_get_time_values(&shadow, src);
> >> -          barrier();
> >> +          rdtsc_barrier();
> >>            offset = pvclock_get_nsec_offset(&shadow);
> >>            ret = shadow.system_timestamp + offset;
> >> -          barrier();
> >> +          rdtsc_barrier();
> >>    } while (version != src->version);
> >>  
> >>    if ((valid_flags & PVCLOCK_TSC_STABLE_BIT) &&
> >>
> > On a guest without SSE2 rdtsc_barrier() will be nop while rmb() will
> > be "lock; addl $0,0(%%esp)". I doubt pvclock will work correctly either
> > way though.
> > 
> > --
> >                     Gleb.
> > 
> Actually it shouldn't matter for KVM, since the page is only updated by
> the vcpu, and the guest is never running while it happens. If Jeremy is
> fine with this, so should I.
If you and Jeremy are fine with this, so should I.

--
                        Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to