qemu-devel
[Top][All Lists]
Advanced

[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: Thu, 1 Sep 2011 19:34:01 +0300
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/
> 
> 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.
But there might be reasons why that is not an issue either
if we look closely enough.

-- 
MST



reply via email to

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