From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH 19/38] KVM: PPC: Add cache flush on page map Date: Wed, 15 Aug 2012 14:53:32 -0500 Message-ID: <502BFE3C.9030809@freescale.com> References: <1344985483-7440-1-git-send-email-agraf@suse.de> <1344985483-7440-20-git-send-email-agraf@suse.de> <502AFA29.3030201@freescale.com> <3882D134-C53C-42D2-BEE5-EC21A07B3937@suse.de> <502BDBAA.6030708@freescale.com> <502BE0AA.9040001@freescale.com> <502BE774.8000903@freescale.com> <9AE6ABF7-3399-4B53-AABE-5C3A45D90036@suse.de> <6EFF12CA-CCFB-4B1D-9E2C-7E2103FD307A@suse.de> <502BEB90.4060905@freescale.com> <3773C769-16E5-4E95-AB2C-E9B164C9D406@suse.de> <502BF0C2.3010101@freescale.com> <78653109-FCF4-4F62-84D8-62A0594B4DF6@suse.de> <502BF2EB.3060902@freescale.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: , KVM list , Benjamin Herrenschmidt To: Alexander Graf Return-path: Received: from va3ehsobe001.messaging.microsoft.com ([216.32.180.11]:41804 "EHLO va3outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932287Ab2HOTxp (ORCPT ); Wed, 15 Aug 2012 15:53:45 -0400 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On 08/15/2012 02:29 PM, Alexander Graf wrote: > > On 15.08.2012, at 21:05, Scott Wood wrote: > >> On 08/15/2012 01:58 PM, Alexander Graf wrote: >>> >>> On 15.08.2012, at 20:56, Scott Wood wrote: >>> >>>> On 08/15/2012 01:51 PM, Alexander Graf wrote: >>>>> >>>>> On 15.08.2012, at 20:33, Scott Wood wrote: >>>>> >>>>>> On 08/15/2012 01:29 PM, Alexander Graf wrote: >>>>>>> Ah, if I read Ben's comment correctly we only need it for rom loads, not always for cpu_physical_memory_rw. >>>>>> >>>>>> Why? >>>>> >>>>> Because guest Linux apparently assumes that DMA'd memory needs to be icache flushed. >>>> >>>> What about breakpoints and other debug modifications? >>> >>> The breakpoint code is arch specific. We can just put an icache flush in there. >> >> That doesn't cover other modifications that a debugger might do >> (including manual poking at code done by a person at the command line). > > Why not? This would go through gdbstub, Not necessarily. I could be poking at memory from the QEMU command line. If there isn't a command for that, there should be. :-) > where we can always put in an icache flush. If you want to cover every individual place where this function is called for non-DMA, fine, though I'd feel more comfortable with something that specifically identifies the access as for DMA. >>>>>> And it's possible (if not necessarily likely) that other guests are >>>> different. >>> >>> Does fsl hardware guarantee icache coherency from device DMA? >> >> I don't think so, but I don't know of any fsl hardware that leaves dirty >> data in the dcache after DMA. Even with stashing on our newer chips, >> the data first goes to memory and then the core is told to prefetch it. > > For Linux, I think we always flush the dcache when flushing the > icache. However, that argument is reasonably valid. We probably want > to flush the dache on DMA, so that a stale icache can fetch it from > memory properly. But I don't see a reason why we would want to do so > for the icache if hardware doesn't do it either. > > But let's get Ben on board here :). The only reason to invalidate the icache on DMA accesses would be to avoid introducing a special case in the QEMU code, unless we find hardware to emulate that does invalidate icache on DMA writes but isn't icache-coherent in general (it's fairly plausable -- icache would act on snoops it sees on the bus, but icache fills wouldn't issue snoops of their own). -Scott