[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [PATCH] virtio: Make memory barriers be memory barriers
Date: Fri, 2 Sep 2011 18:45:50 +0300
User-agent: Mutt/1.5.21 (2010-09-15)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]