From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R91m7-0003EQ-VB for qemu-devel@nongnu.org; Wed, 28 Sep 2011 17:34:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R91m6-0003vd-VQ for qemu-devel@nongnu.org; Wed, 28 Sep 2011 17:34:43 -0400 From: Benjamin Herrenschmidt In-Reply-To: <4E838F85.6070008@freescale.com> 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> <4E838F85.6070008@freescale.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 29 Sep 2011 07:34:26 +1000 Message-ID: <1317245666.29415.111.camel@pasglop> Mime-Version: 1.0 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: Scott Wood Cc: kvm , qemu-devel Developers , Jan Kiszka , Alexander Graf , David Gibson , "qemu-ppc@nongnu.org" On Wed, 2011-09-28 at 16:20 -0500, Scott Wood wrote: > 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. I see what you mean. A DMA would have had an implicit cache flush while qemu memcpy'ing to the guest won't. Hrm. I'm not sure any guest relies on that since architecturally, the HW is permitted to do cache intervention tricks, and rather than flush, transfer the data directly to the cache that originally contained the lines (cache injection). We do even support that on some embedded stuff. In any case, we should then make that depend on a flag, because it's certainly unnecessary on P5, P6 and P7 which have a snooping icache and can be costly. Cheers, Ben.