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