[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: David Gibson
Subject: Re: [Qemu-devel] [PATCH] virtio: Make memory barriers be memory barriers
Date: Fri, 2 Sep 2011 10:11:28 +1000
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Sep 01, 2011 at 06:14:34PM +0200, Paolo Bonzini wrote:
> On 09/01/2011 05:30 PM, Michael S. Tsirkin wrote:
> >>>  The virtio code already has memory barrier wmb() macros in the code.
> >>>  However they are was defined as no-ops.  The comment claims that real
> >>>  barriers are not necessary because the code does not run concurrent.
> >>>  However, with kvm and io-thread enabled, this is not true and this qemu
> >>>  code can indeed run concurrently with the guest kernel.  This does not
> >>>  cause problems on x86 due to it's strongly ordered storage model, but it
> >>>  causes a race leading to virtio errors on POWER which has a relaxed 
> >>> storage
> >>>  ordering model.
> >
> >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/

Not to mention that pcc is not the only non-x86 architecture.  I don't
know all their storage models off hand, but the point is that there is
a required order to these writes, so there should be a memory barrier.

David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!

reply via email to

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