From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH 19/38] KVM: PPC: Add cache flush on page map Date: Wed, 15 Aug 2012 13:33:52 -0500 Message-ID: <502BEB90.4060905@freescale.com> References: <1344985483-7440-1-git-send-email-agraf@suse.de> <1344985483-7440-20-git-send-email-agraf@suse.de> <502AFA29.3030201@freescale.com> <3882D134-C53C-42D2-BEE5-EC21A07B3937@suse.de> <502BDBAA.6030708@freescale.com> <502BE0AA.9040001@freescale.com> <502BE774.8000903@freescale.com> <9AE6ABF7-3399-4B53-AABE-5C3A45D90036@suse.de> <6EFF12CA-CCFB-4B1D-9E2C-7E2103FD307A@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: , KVM list To: Alexander Graf Return-path: In-Reply-To: <6EFF12CA-CCFB-4B1D-9E2C-7E2103FD307A@suse.de> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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. > Ah, if I read Ben's comment correctly we only need it for rom loads, not always for cpu_physical_memory_rw. Why? -Scott