[Qemu-devel] Re: [PATCH] qemu/virtio: make wmb compiler barrier + comments

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

On Wed, Nov 11, 2009 at 01:01:03PM +0000, Paul Brook wrote:
> On Wednesday 11 November 2009, Michael S. Tsirkin wrote:
> > On Wed, Nov 11, 2009 at 01:34:12AM +0000, Paul Brook wrote:
> > > On Monday 26 October 2009, Michael S. Tsirkin wrote:
> > > > wmb must be at least a compiler barrier, even without SMP.
> > >
> > > Why?
> > 
> > Because virtio code might run on a separate thread from guest.
> > If compiler reorders writes, guest might see inconsistent data.
> 
> If you've got threads running in parallel (which may be running on separate 
> CPUs)

Yes, but you asked what happens without SMP (single CPU).

> then you need an actual memory barrier to prevent the hardware 
> reordering things behind your back.
> 
> If you've already used locking to avoid simultaneous execution then the 
> locking routines already include memory barriers.

You can not share a lock with guest.

> A "compiler memory barrier" provides absolutely no guarantees in a 
> multithreaded environment. They are sometimes useful in a single threaded 
> interruptable system (i.e. UNIX signals), but that's definitely not the case 
> here.
> 
> Paul

"absolutely no guarantees" is surely wrong.  On intel CPUs, regular
memory writes are never re-ordered by the CPU.  Only compiler can
reorder such writes.  So yes, on this platform a "compiler barrier" does
provide necessary and sufficient guarantees agains write reordering in a
multithreaded environment, both with and without SMP.

-- 
MST