On Wed, Mar 04, 2015 at 01:24:52PM -0500, Ryan Stone wrote:
> On Wed, Feb 4, 2015 at 3:26 AM, Bryan Venteicher <bry...@freebsd.org> wrote:
> > +static void
> > +pvclock_read_time_info(struct pvclock_vcpu_time_info *ti,
> > + uint64_t *cycles, uint8_t *flags)
> > +{
> > + uint32_t version;
> > +
> > + do {
> > + version = ti->version;
> > + rmb();
> > + *cycles = ti->system_time + pvclock_get_nsec_offset(ti);
> > + *flags = ti->flags;
> > + rmb();
> > + } while ((ti->version & 1) != 0 || ti->version != version);
> > +}
>
> The Linux implementation of this does a "rdtsc_barrier();" in place of
> the rmb(), and in some situations that appears to result in a full
> mfence, not just an lfence (the code is macro soup so it's difficult
> to understand what's happening). Are you sure that the rmb() is
> enough? I believe that the concern is whether the rdtsc() itself is
> allowed to be re-ordered around an lfence.
>
> This stack overflow answer seems to indicate the a full mfence is
> necessary on AMD processors:
>
> http://stackoverflow.com/questions/12631856/difference-between-rdtscp-rdtsc-memory-and-cpuid-rdtsc
Yes, Intel declares that lfence is enough, but for AMD the mfence should
be used. See r238973/r238975 and sys/x86/x86/tsc.c.
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
