From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:46859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVBoE-0001gM-76 for qemu-devel@nongnu.org; Thu, 17 May 2012 21:16:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SVBoC-0002Wk-FT for qemu-devel@nongnu.org; Thu, 17 May 2012 21:16:45 -0400 Received: from gate.crashing.org ([63.228.1.57]:42304) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SVBoC-0002WS-5m for qemu-devel@nongnu.org; Thu, 17 May 2012 21:16:44 -0400 Message-ID: <1337303787.2530.4.camel@pasglop> From: Benjamin Herrenschmidt Date: Fri, 18 May 2012 11:16:27 +1000 In-Reply-To: <4FB57712.7030806@codemonkey.ws> 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> <1337215928.30558.28.camel@pasglop> <4FB46257.3060706@codemonkey.ws> <1337222685.30558.34.camel@pasglop> <4FB57712.7030806@codemonkey.ws> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 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: "Michael S. Tsirkin" , qemu-devel@nongnu.org, David Gibson On Thu, 2012-05-17 at 17:09 -0500, Anthony Liguori wrote: > ld/st should not ever be used by device emulation because they use a concept of > "target endianness" that doesn't exist for devices. Hrm, there's a bit of both, some of them even have explicit endianness arguments and some of them are definitely used by bits of hw/* virtio core uses them directly as well but then virtio also does explicit barriers (though I need to double check whether it does enough of them in all the right places). > So no, I don't think you need to put barriers there as they should only be used > by VCPU emulation code. I'm ok to leave them alone for now, I'll give a quick look at the various callers. > > Note that with the above, cpu_physical_memory_map and unmap will > > imply a barrier when using bounce buffers, it would make sense to also > > provide the same barrier when not. > > > > That does actually make sense for the same reason explained above, > > ie, when those are used for a DMA transfer via async IO, that guarantees > > ordering of the "block" vs. surrounding accesses even if accesses within > > the actual map/unmap region are not ordered vs. each other. > > > > Any objection ? > > I think so. I'd like to see a better comment about barrier usage at the top of > the file or something like that too. Ok. Cheers, Ben. > Regards, > > Anthony Liguori > > > > > Cheers, > > Ben. > > > > > >