From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:39837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWO1n-0003nE-Dn for qemu-devel@nongnu.org; Mon, 21 May 2012 04:31:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWO1f-0007xi-1H for qemu-devel@nongnu.org; Mon, 21 May 2012 04:31:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34326) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWO1e-0007xX-Pb for qemu-devel@nongnu.org; Mon, 21 May 2012 04:31:34 -0400 Date: Mon, 21 May 2012 11:31:33 +0300 From: "Michael S. Tsirkin" Message-ID: <20120521083132.GI4674@redhat.com> References: <1337213257.30558.22.camel@pasglop> <1337214293.30558.25.camel@pasglop> <4FB5F1FD.9020009@redhat.com> <1337329136.2513.7.camel@pasglop> <4FB60EFF.6070205@redhat.com> <1337379992.2513.17.camel@pasglop> <4FB74AB0.7090608@redhat.com> <1337549768.2458.0.camel@pasglop> <1337565405.2458.12.camel@pasglop> <4FB9F89A.90702@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FB9F89A.90702@redhat.com> Subject: Re: [Qemu-devel] [PATCH] Add a memory barrier to guest memory access functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, Anthony Liguori , David Gibson On Mon, May 21, 2012 at 10:11:06AM +0200, Paolo Bonzini wrote: > Il 21/05/2012 03:56, Benjamin Herrenschmidt ha scritto: > > I don't see an obvious need to provide a "relaxed" variant of the > > later at this stage, a quick grep doesn't seem to show that most cases > > where it's used are either not performance sensitive or the barrier > > makes sense, but feel free to prove me wrong :-) > > The only problem here is that you have useless memory barriers when > calling cpu_physical_memory_map in a loop (see virtqueue_map_sg). > > Paolo More than that. smp_mb is pretty expensive. You often can do just smp_wmb and smp_rmb and that is very cheap. Many operations run in the vcpu context or start when guest exits to host and work is bounced from there and thus no barrier is needed here. Example? start_xmit in e1000. Executed in vcpu context so no barrier is needed. virtio of course is another example since it does its own barriers. But even without that, virtio_blk_handle_output runs in vcpu context. But more importantly, this hack just sweeps the dirt under the carpet. Understanding the interaction with guest drivers is important anyway. So I really don't see why don't we audit devices and add proper barriers. -- MST