From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 7 Aug 2013 11:47:54 +1000 From: Paul Mackerras To: Scott Wood Subject: Re: [PATCH 5/6 v2] kvm: powerpc: booke: Add linux pte lookup like booke3s Message-ID: <20130807014754.GA31007@iris.ozlabs.ibm.com> References: <1375355558-19187-6-git-send-email-Bharat.Bhushan@freescale.com> <1375484319.26902.4.camel@snotra.buserror.net> <1375485408.15999.67.camel@pasglop> <6A3DF150A5B70D4F9B66A25E3F7C888D070F8FCC@039-SN2MPN1-012.039d.mgd.msft.net> <1375503847.15999.80.camel@pasglop> <6A3DF150A5B70D4F9B66A25E3F7C888D070FAD49@039-SN2MPN1-012.039d.mgd.msft.net> <1375730341.13074.38.camel@snotra.buserror.net> <6A3DF150A5B70D4F9B66A25E3F7C888D070FBE3B@039-SN2MPN1-012.039d.mgd.msft.net> <20130807002408.GE19254@iris.ozlabs.ibm.com> <1375837894.5600.64.camel@snotra.buserror.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <1375837894.5600.64.camel@snotra.buserror.net> Cc: Wood Scott-B07421 , "kvm@vger.kernel.org" , "agraf@suse.de" , "kvm-ppc@vger.kernel.org" , Bhushan Bharat-R65777 , "linuxppc-dev@lists.ozlabs.org" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, Aug 06, 2013 at 08:11:34PM -0500, Scott Wood wrote: > On Wed, 2013-08-07 at 10:24 +1000, Paul Mackerras wrote: > > On Tue, Aug 06, 2013 at 07:02:48AM +0000, Bhushan Bharat-R65777 wrote: > > > > > > I am trying to me the Linux pte search and update generic so that this can be used for powerpc as well. > > > > > > I am not sure which of the below two should be ok, please help > > > > Given that the BookE code uses gfn_to_pfn_memslot() to get the host > > pfn, and then kvm_set_pfn_dirty(pfn) on pages that you're going to let > > the guest write to, I don't think you need to set the dirty and/or > > accessed bits in the Linux PTE explicitly. If you care about the > > WIMGE bits you can do find_linux_pte_or_hugepte() and just look at the > > PTE, but you really should be using mmu_notifier_retry() to guard > > against concurrent changes to the Linux PTE. See the HV KVM code or > > patch 21 of my recent series to see how it's used. > > Hmm... we only get a callback on invalidate_range_start(), not > invalidate_range_end() (and even if we did get a callback for the > latter, it'd probably be racy). So we may have a problem here > regardless of getting WIMG from the PTE, unless it's guaranteed that > hva_to_pfn() will fail after invalidate_range_start(). No, it's not guaranteed. You have to use mmu_notifier_retry(). It tells you if either (a) some sort of invalidation has happened since you snapshotted kvm->mmu_notifier_seq, or (b) an invalidate_range_start...end sequence is currently in progress. In either case you should discard any PTE or pfn information you collected and retry. > > You probably should be calling kvm_set_pfn_accessed() as well. > > Yeah... I think it'll only affect the quality of page-out decisions (as > opposed to corruption and such), but still it should be fixed. Right. Paul.