From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42196) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVCcl-0006I2-Rj for qemu-devel@nongnu.org; Thu, 17 May 2012 22:09:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SVCck-0004LO-1M for qemu-devel@nongnu.org; Thu, 17 May 2012 22:08:59 -0400 Received: from ozlabs.org ([203.10.76.45]:55539) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVCcj-0004L4-Mu for qemu-devel@nongnu.org; Thu, 17 May 2012 22:08:57 -0400 Date: Fri, 18 May 2012 11:04:10 +1000 From: David Gibson Message-ID: <20120518010410.GK22069@truffala.fritz.box> References: <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> <1337215928.30558.28.camel@pasglop> <4FB46257.3060706@codemonkey.ws> <1337222685.30558.34.camel@pasglop> <4FB57712.7030806@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4FB57712.7030806@codemonkey.ws> Subject: Re: [Qemu-devel] [RFC/PATCH] Add a memory barrier to guest memory access functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, "Michael S. Tsirkin" On Thu, May 17, 2012 at 05:09:22PM -0500, Anthony Liguori wrote: > On 05/16/2012 09:44 PM, Benjamin Herrenschmidt wrote: > >On Wed, 2012-05-16 at 21:28 -0500, Anthony Liguori wrote: > > > >>>@@ -2794,6 +2795,9 @@ void *qemu_get_ram_ptr(ram_addr_t addr) > >>> { > >>> RAMBlock *block; > >>> > >>>+ /* We ensure ordering for all DMA transactions */ > >>>+ dma_mb(); > >>>+ > >> > >>I get being conservative, but I don't think this makes a lot of sense. There > >>are cases where the return of this function is cached (like the VGA ram area). > >>I think it would make more sense if you explicitly put a barrier after write > >>operations. > > > >Well, it depends ... sure something that caches the result is akin to > >map/unmap and responsible for doing its own barriers between accesses, > >however as a whole, this means that an entire map/unmap section is > >ordered surrounding accesses which is actually not a bad idea. > > > >Anyway, I'll post a different patch that adds the barrier more > >selectively to: > > > > - cpu_physical_memory_rw (that's the obvious main one) > > - cpu_physical_memory_write_rom (probably overkill but > > not a fast path so no big deal) > > - ld*_* and st*_* (or do you think these should require > > explicit barriers in the callers ?) > > ld/st should not ever be used by device emulation because they use a > concept of "target endianness" that doesn't exist for devices. Ah, but there are the explicit endian versions, which were used routinely until I replaced a lot of them with ld*_dma(). -- 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