From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60582) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzHoE-000412-8L for qemu-devel@nongnu.org; Thu, 01 Sep 2011 20:40:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QzHoC-000132-PN for qemu-devel@nongnu.org; Thu, 01 Sep 2011 20:40:38 -0400 Received: from e23smtp09.au.ibm.com ([202.81.31.142]:42039) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QzHoC-00012t-6u for qemu-devel@nongnu.org; Thu, 01 Sep 2011 20:40:36 -0400 Received: from /spool/local by au.ibm.com with XMail ESMTP for from ; Fri, 2 Sep 2011 01:37:21 +1000 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p820dD531974284 for ; Fri, 2 Sep 2011 10:39:15 +1000 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p820dDkn027103 for ; Fri, 2 Sep 2011 10:39:13 +1000 Date: Fri, 2 Sep 2011 10:11:28 +1000 From: David Gibson Message-ID: <20110902001128.GN11906@yookeroo.fritz.box> References: <1314857389-13363-1-git-send-email-david@gibson.dropbear.id.au> <20110901153020.GB10989@redhat.com> <4E5FAF6A.70205@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E5FAF6A.70205@redhat.com> Subject: Re: [Qemu-devel] [PATCH] virtio: Make memory barriers be memory barriers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: aliguori@us.ibm.com, "Michael S. Tsirkin" , aik@ozlabs.ru, rusty@rustcorp.com.au, agraf@suse.de, qemu-devel@nongnu.org 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_! http://www.ozlabs.org/~dgibson