Re: [Qemu-devel] [PATCH] virtio: Make memory barriers be memory barriers

["Michael S. Tsirkin" <mst@redhat.com>]

On Thu, Sep 01, 2011 at 04:31:09PM -0400, Paolo Bonzini wrote:
> > > > Why not limit the change to ppc then?
> > >
> > > Because the bug is masked by the x86 memory model, but it is still
> > > there even there conceptually. It is not really true that x86 does
> > > not need memory barriers, though it doesn't in this case:
> > >
> > > http://bartoszmilewski.wordpress.com/2008/11/05/who-ordered-memory-fences-on-an-x86/
> > >
> > > Paolo
> > 
> > Right.
> > To summarize, on x86 we probably want wmb and rmb to be compiler
> > barrier only. Only mb might in theory need to be an mfence.
> 
> No, wmb needs to be sfence and rmb needs to be lfence.  GCC does
> not provide those, so they should become __sync_synchronize() too,
> or you should use inline assembly.
> 
> > But there might be reasons why that is not an issue either
> > if we look closely enough.
> 
> Since the ring buffers are not using locked instructions (no xchg
> or cmpxchg) the barriers simply must be there, even on x86.  Whether
> it works in practice is not interesting, only the formal model is
> interesting.
> 
> Paolo

Well, can you describe an issue in virtio that lfence/sfence help solve
in terms of a memory model please?
Pls note that guest uses smp_ variants for barriers.

-- 
MST