From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:48118) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R91YC-0008Uq-Fh for qemu-devel@nongnu.org; Wed, 28 Sep 2011 17:20:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R91YB-0007HQ-C5 for qemu-devel@nongnu.org; Wed, 28 Sep 2011 17:20:20 -0400 Message-ID: <4E838F85.6070008@freescale.com> Date: Wed, 28 Sep 2011 16:20:05 -0500 From: Scott Wood MIME-Version: 1.0 References: <4E832DE3.40503@siemens.com> <5B15DB32-18DF-4637-AD37-4BE652A031E3@suse.de> <4E83330C.2080901@siemens.com> <4E8358FD.6030408@freescale.com> <1317243755.29415.99.camel@pasglop> In-Reply-To: <1317243755.29415.99.camel@pasglop> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu-kvm: Role of flush_icache_range on PPC List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Herrenschmidt Cc: kvm , qemu-devel Developers , Jan Kiszka , Alexander Graf , David Gibson , "qemu-ppc@nongnu.org" On 09/28/2011 04:02 PM, Benjamin Herrenschmidt wrote: > On Wed, 2011-09-28 at 12:27 -0500, Scott Wood wrote: > >> Why would it need to be synchronous? Even if it's asynchronous emulated >> DMA, we don't want it sitting around only in a data cache that >> instruction fetches won't snoop. > > Except that this is exactly what happens on real HW :-) DMA does not normally go straight to data cache, at least on hardware I'm familiar with. > The guest will do the necessary invalidations. DMA doesn't keep the > icache coherent on HW, why should it on kvm/qemu ? Sure, if there might be stale stuff in the icache, the guest will need to invalidate that. But when running on real hardware, an OS does not need to flush it out of data cache after a DMA transaction[1]. So technically we just want a flush_dcache_range() for DMA. It's moot unless we can distinguish DMA writes from breakpoint writes, though. -Scott [1] Most OSes may do this anyway, to avoid needing to special case when the dirtying is done entirely by DMA (or to avoid making assumptions that could be broken by weird hardware), but that doesn't mean QEMU/KVM should assume that -- maybe unless there's enough performance to be gained by looking like the aforementioned "weird hardware" in certain configurations.