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: >>> >>> On 15.08.2012, at 20:27, Alexander Graf wrote: >>> >>>> >>>> On 15.08.2012, at 20:16, Scott Wood wrote: >>>> >>>>> On 08/15/2012 01:01 PM, Alexander Graf wrote: >>>>>> >>>>>> On 15.08.2012, at 19:47, Scott Wood wrote: >>>>>> >>>>>>> On 08/15/2012 12:27 PM, Alexander Graf wrote: >>>>>>>> >>>>>>>> On 15.08.2012, at 19:26, Scott Wood wrote: >>>>>>>> >>>>>>>>> On 08/15/2012 04:52 AM, Alexander Graf wrote: >>>>>>>>>> >>>>>>>>>> On 15.08.2012, at 03:23, Scott Wood wrote: >>>>>>>>>> >>>>>>>>>>> On 08/14/2012 06:04 PM, Alexander Graf wrote: >>>>>>>>>>>> When we map a page that wasn't icache cleared before, do so when first >>>>>>>>>>>> mapping it in KVM using the same information bits as the Linux mapping >>>>>>>>>>>> logic. That way we are 100% sure that any page we map does not have stale >>>>>>>>>>>> entries in the icache. >>>>>>>>>>> >>>>>>>>>>> We're not really 100% sure of that -- this only handles the case where >>>>>>>>>>> the kernel does the dirtying, not when it's done by QEMU or the guest. >>>>>>>>>> >>>>>>>>>> When the guest does it, the guest is responsible for clearing the >>>>>>>>>> icache. Same for QEMU. It needs to clear it when doing DMA. >>>>>>>>> >>>>>>>>> Sure. I was just worried that that commit message could be taken the >>>>>>>>> wrong way, as in "we no longer need the QEMU icache flushing patch". >>>>>>>>> >>>>>>>>>> However, what is still broken would be a direct /dev/mem map. There >>>>>>>>>> QEMU should probably clear the icache before starting the guest, in >>>>>>>>>> case another guest was running on that same memory before. >>>>>>>>>> Fortunately, we don't have that mode available in upstream QEMU :). >>>>>>>>> >>>>>>>>> How is QEMU loading images different if it's /dev/mem versus ordinary >>>>>>>>> anonymous memory? You probably won't have stale icache data in the >>>>>>>>> latter case (which makes it less likely to be a problem in pratice), but >>>>>>>>> in theory you could have data that still hasn't left the dcache. >>>>>>>> >>>>>>>> It's the same. I just talked to Ben about this today in a different context and we should be safe :). >>>>>>> >>>>>>> Safe how? >>>>>>> >>>>>>> If it's truly the same, we're definitely not safe, since I had problems >>>>>>> with this using /dev/mem (particularly when changing the kernel image >>>>>>> without a host reboot) before I put in the icache flush patch. >>>>>> >>>>>> QEMU needs to icache flush everything it puts into guest memory. >>>>> >>>>> Yes. I thought you meant we should be safe as things are now. >>>> >>>> Hrm. What happened to your patch that flushes the icache on cpu_physical_memory_rw? >> >> IIRC Ben wanted it conditionalized to not slow things down on >> icache-coherent systems, and I never got around to respinning it. > > No, he was saying that DMA doesn't flush the icache: > > http://thread.gmane.org/gmane.comp.emulators.qemu/119022/focus=119086 I recall someone asking for it to be made conditional, but I don't have time to look it up right now -- I want to try to get some U-Boot stuff done before the end of the merge window tomorrow. >>> 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? And it's possible (if not necessarily likely) that other guests are different. -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
