From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R08M3-0000ek-Gx for qemu-devel@nongnu.org; Sun, 04 Sep 2011 04:47:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R08M2-0006Lw-FM for qemu-devel@nongnu.org; Sun, 04 Sep 2011 04:47:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46799) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R08M2-0006Lq-8O for qemu-devel@nongnu.org; Sun, 04 Sep 2011 04:47:02 -0400 Date: Sun, 4 Sep 2011 11:47:50 +0300 From: "Michael S. Tsirkin" Message-ID: <20110904084750.GB18368@redhat.com> References: <20110901163359.GB11620@redhat.com> <786649703.1049386.1314909069542.JavaMail.root@zmail07.collab.prod.int.phx2.redhat.com> <20110902154549.GA18368@redhat.com> <4E62538B.7030409@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E62538B.7030409@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, aik@ozlabs.ru, rusty@rustcorp.com.au, agraf@suse.de, qemu-devel@nongnu.org, David Gibson On Sat, Sep 03, 2011 at 06:19:23PM +0200, Paolo Bonzini wrote: > On 09/02/2011 05:45 PM, Michael S. Tsirkin wrote: > >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. > > /* Make sure buffer is written before we update index. */ > wmb(); > > Without it, a guest could see a partially updated buffer, because > the buffer and index writes are unlocked stores to different > locations. Sorry, I still don't understand. Yes, they are unlocked stores to different locations. How does it follow that a guest could see a partially updated buffer? Just to make sure - we are talking about x86 here, not ppc, right? > Even if the guest uses barriers, with ioeventfd it will only order > the CPU that is running the guest, not the one that is running the > iothread. In fact I'm surprised that it works at all under x86 with > ioeventfd. > > Paolo I can try to explain if I understand the problem you see. -- MST