From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52627) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWNi9-0007CT-Dy for qemu-devel@nongnu.org; Mon, 21 May 2012 04:11:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SWNi2-0003dX-Te for qemu-devel@nongnu.org; Mon, 21 May 2012 04:11:24 -0400 Received: from mx1.redhat.com ([209.132.183.28]:2687) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SWNi2-0003dS-LK for qemu-devel@nongnu.org; Mon, 21 May 2012 04:11:18 -0400 Message-ID: <4FB9F89A.90702@redhat.com> Date: Mon, 21 May 2012 10:11:06 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1336625347-10169-1-git-send-email-benh@kernel.crashing.org> <1336625347-10169-14-git-send-email-benh@kernel.crashing.org> <4FB1A8BF.7060503@codemonkey.ws> <20120515014449.GF30229@truffala.fritz.box> <1337142938.6727.122.camel@pasglop> <4FB4028F.7070003@codemonkey.ws> <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> In-Reply-To: <1337565405.2458.12.camel@pasglop> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Benjamin Herrenschmidt Cc: David Gibson , qemu-devel@nongnu.org, Anthony Liguori , "Michael S. Tsirkin" 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