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

[Paul Brook <paul@codesourcery.com>]

> > > > > 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).

I assumed you meant guest SMP where guest code can run in parallel with host 
code.  My understanding is that qemu currently does not implement this, and 
everything always runs in lockstep.
 
> > 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.

No, but you can prevent the guest code running at the same time as host code.

> > 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.
> 
> "absolutely no guarantees" is surely wrong.  On intel CPUs, regular
> memory writes are never re-ordered by the CPU.  

Technically true, however reads and writes may be reordered. 
If you don't need real barriers, then why does the kvm code have them? Also, 
there's no indication that your code is specific to Intel CPUs.

Paul