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:05:15 -0500 Message-ID: <502BF2EB.3060902@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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: , KVM list To: Alexander Graf Return-path: Received: from am1ehsobe004.messaging.microsoft.com ([213.199.154.207]:55493 "EHLO am1outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751026Ab2HOTFV (ORCPT ); Wed, 15 Aug 2012 15:05:21 -0400 In-Reply-To: <78653109-FCF4-4F62-84D8-62A0594B4DF6@suse.de> Sender: kvm-owner@vger.kernel.org List-ID: 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). It's not really the breakpoint that's the special case, it's things that the guest thinks of as DMA -- and differentiating that seems like a questionable optimization. If the guest is going to flush anyway, is there any significant performance penalty to flushing twice? The second time would just be a no-op beyond doing the MMU/cache lookup. >> 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. -Scott