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? Ah, if I read Ben's comment correctly we only need it for rom loads, not always for cpu_physical_memory_rw. 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
