[SeaBIOS] [PATCH] virtio: clean up memory barrier usage

Gleb Natapov gleb at redhat.com
Mon May 24 11:55:30 CEST 2010


On Mon, May 24, 2010 at 12:39:41PM +0300, Michael S. Tsirkin wrote:
> On Mon, May 24, 2010 at 12:35:21PM +0300, Gleb Natapov wrote:
> > On Thu, May 20, 2010 at 04:36:32PM +0300, Michael S. Tsirkin wrote:
> > > diff --git a/src/virtio-ring.h b/src/virtio-ring.h
> > > index 3fb86fe..8b546f4 100644
> > > --- a/src/virtio-ring.h
> > > +++ b/src/virtio-ring.h
> > > @@ -9,8 +9,9 @@
> > >  
> > >  #define virt_to_phys(v) (unsigned long)(v)
> > >  #define phys_to_virt(p) (void*)(p)
> > > -#define wmb() barrier()
> > > -#define mb() barrier()
> > > +/* Compiler barrier is enough as an x86 CPU does not reorder reads or writes */
> > > +#define smp_rmb() barrier()
> > > +#define smp_wmb() barrier()
> > >  
> > I thought you were going to use real memory barriers (although we
> > concluded compiler barrier should be enough, but it's better to be safe
> > then sorry).
> > 
> > --
> > 			Gleb.
> 
> On x86, ops of the same kind are ordered by CPU, so all we need to do is
> 1. avoid depending on order between reads and writes
> 2. prevent the compiler from reordering memory accesses
> 
So on Linux smp_rmb() and smp_wmb() are just compiler barriers too? (look
like they are). In that case lets use barrier() directly no need to
obfuscate the code.

--
			Gleb.



More information about the SeaBIOS mailing list