From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:49931) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R02Vi-00064a-On for qemu-devel@nongnu.org; Sat, 03 Sep 2011 22:32:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R02Vh-0005Ii-7n for qemu-devel@nongnu.org; Sat, 03 Sep 2011 22:32:38 -0400 Received: from e23smtp01.au.ibm.com ([202.81.31.143]:49103) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R02Vg-0005IN-JT for qemu-devel@nongnu.org; Sat, 03 Sep 2011 22:32:37 -0400 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.31.245]) by e23smtp01.au.ibm.com (8.14.4/8.13.1) with ESMTP id p842RXWZ006571 for ; Sun, 4 Sep 2011 12:27:33 +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 p842WFe31794246 for ; Sun, 4 Sep 2011 12:32: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 p842VvlU011303 for ; Sun, 4 Sep 2011 12:32:13 +1000 Date: Sun, 4 Sep 2011 00:46:35 +1000 From: David Gibson Message-ID: <20110903144635.GD12965@yookeroo.fritz.box> References: <20110901163359.GB11620@redhat.com> <786649703.1049386.1314909069542.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <20110902154549.GA18368@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110902154549.GA18368@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: "Michael S. Tsirkin" Cc: aliguori@us.ibm.com, aik@ozlabs.ru, rusty@rustcorp.com.au, qemu-devel@nongnu.org, agraf@suse.de, Paolo Bonzini On Fri, Sep 02, 2011 at 06:45:50PM +0300, Michael S. Tsirkin wrote: > On Thu, Sep 01, 2011 at 04:31:09PM -0400, Paolo Bonzini wrote: > > > > > 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. > > > > No, wmb needs to be sfence and rmb needs to be lfence. GCC does > > not provide those, so they should become __sync_synchronize() too, > > or you should use inline assembly. > > > > > But there might be reasons why that is not an issue either > > > if we look closely enough. > > > > Since the ring buffers are not using locked instructions (no xchg > > or cmpxchg) the barriers simply must be there, even on x86. Whether > > it works in practice is not interesting, only the formal model is > > interesting. > > > > Paolo > > Well, can you describe an issue in virtio that lfence/sfence help solve > in terms of a memory model please? > Pls note that guest uses smp_ variants for barriers. Ok, so, I'm having a bit of trouble with the fact that I'm having to argue the case that things the protocol requiress to be memory barriers actually *be* memory barriers on all platforms. I mean argue for a richer set of barriers, with per-arch minimal implementations instead of the large but portable hammer of sync_synchronize, if you will. But just leaving them out on x86!? Seriously, wtf? Do you enjoy having software that works chiefly by accident? -- 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