"Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: > On Thu, Mar 07, 2013 at 02:48:24PM +1100, Rusty Russell wrote: >> "Michael S. Tsirkin" <mst@xxxxxxxxxx> writes: >> > On Wed, Mar 06, 2013 at 03:54:42PM +1100, Rusty Russell wrote: >> >> In the coming vringh_test, we share an mmap with another userspace process >> >> for testing. This requires real barriers. >> >> >> >> Signed-off-by: Rusty Russell <rusty@xxxxxxxxxxxxxxx> >> >> >> >> diff --git a/tools/virtio/asm/barrier.h b/tools/virtio/asm/barrier.h >> >> index aff61e1..7a63693 100644 >> >> --- a/tools/virtio/asm/barrier.h >> >> +++ b/tools/virtio/asm/barrier.h >> >> @@ -3,8 +3,8 @@ >> >> #define mb() __sync_synchronize() >> >> >> >> #define smp_mb() mb() >> >> -# define smp_rmb() barrier() >> >> -# define smp_wmb() barrier() >> >> +# define smp_rmb() mb() >> >> +# define smp_wmb() mb() >> >> /* Weak barriers should be used. If not - it's a bug */ >> >> # define rmb() abort() >> >> # define wmb() abort() >> > >> > Hmm this seems wrong on x86 which has strong order in hardware. >> > It should not matter whether the other side is a userspace >> > process or a kernel thread. >> >> Actually, this code is completely generic now, though overkill for x86 smp_wmb(): >> >> Interestingly, when I try defining them, 32-bit x86 slows down (it seems >> that gcc is using "lock orl $0x0,(%esp)" for __sync_synchronize()).: > > Well this depends on which arch you are building for. > We saw this in qemu too, see e.g. include/qemu/atomic.h in qemu. Hmm, I thought x86 had load reordering, but it seems that was only some older chips, which we can consider obsolete. I learned something... I've dropped the patch. Thanks, Rusty. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
