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, where we can always put in an icache flush. > 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. I would hope the guest is clever enough to only icache flush when we actually execute from these pages. > >>> 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 :). Alex -- 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
