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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
