From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N8D2v-0004ax-Ca for qemu-devel@nongnu.org; Wed, 11 Nov 2009 08:15:37 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N8D2q-0004U9-1t for qemu-devel@nongnu.org; Wed, 11 Nov 2009 08:15:36 -0500 Received: from [199.232.76.173] (port=45631 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N8D2p-0004Tm-Q6 for qemu-devel@nongnu.org; Wed, 11 Nov 2009 08:15:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:62678) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N8D2p-0007I7-CI for qemu-devel@nongnu.org; Wed, 11 Nov 2009 08:15:31 -0500 Date: Wed, 11 Nov 2009 15:12:53 +0200 From: "Michael S. Tsirkin" Message-ID: <20091111131253.GC23036@redhat.com> References: <20091026131715.GA25271@redhat.com> <200911110134.13064.paul@codesourcery.com> <20091111093737.GA3276@redhat.com> <200911111301.03427.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911111301.03427.paul@codesourcery.com> Subject: [Qemu-devel] Re: [PATCH] qemu/virtio: make wmb compiler barrier + comments List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu-devel@nongnu.org On Wed, Nov 11, 2009 at 01:01:03PM +0000, Paul Brook wrote: > On Wednesday 11 November 2009, Michael S. Tsirkin wrote: > > On Wed, Nov 11, 2009 at 01:34:12AM +0000, Paul Brook wrote: > > > On Monday 26 October 2009, Michael S. Tsirkin wrote: > > > > wmb must be at least a compiler barrier, even without SMP. > > > > > > Why? > > > > Because virtio code might run on a separate thread from guest. > > If compiler reorders writes, guest might see inconsistent data. > > If you've got threads running in parallel (which may be running on separate > CPUs) Yes, but you asked what happens without SMP (single CPU). > then you need an actual memory barrier to prevent the hardware > reordering things behind your back. > > If you've already used locking to avoid simultaneous execution then the > locking routines already include memory barriers. You can not share a lock with guest. > A "compiler memory barrier" provides absolutely no guarantees in a > multithreaded environment. They are sometimes useful in a single threaded > interruptable system (i.e. UNIX signals), but that's definitely not the case > here. > > Paul "absolutely no guarantees" is surely wrong. On intel CPUs, regular memory writes are never re-ordered by the CPU. Only compiler can reorder such writes. So yes, on this platform a "compiler barrier" does provide necessary and sufficient guarantees agains write reordering in a multithreaded environment, both with and without SMP. -- MST