svn commit: r278183 - in head/sys: amd64/include conf dev/xen/timer i386/include i386/xen x86/include x86/x86
Ryan Stone
rysto32 at gmail.com
Wed Mar 4 18:24:54 UTC 2015
On Wed, Feb 4, 2015 at 3:26 AM, Bryan Venteicher <bryanv at 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
More information about the svn-src-all
mailing list