From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [PATCH] xen/balloon: flush unused mappings before updating P2M table Date: Fri, 14 Mar 2014 18:44:54 +0000 Message-ID: <53234E26.7050706@citrix.com> References: <1394814064-9136-1-git-send-email-wei.liu2@citrix.com> <532344FE.7050407@citrix.com> <20140314182750.GE16807@zion.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1WOX6J-0000bM-AD for xen-devel@lists.xenproject.org; Fri, 14 Mar 2014 18:44:59 +0000 In-Reply-To: <20140314182750.GE16807@zion.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: xen-devel@lists.xenproject.org, Boris Ostrovsky , Tim Deegan List-Id: xen-devel@lists.xenproject.org On 14/03/14 18:27, Wei Liu wrote: > On Fri, Mar 14, 2014 at 06:05:50PM +0000, David Vrabel wrote: >> On 14/03/14 16:21, Wei Liu wrote: >>> Xen balloon driver will update ballooned out pages' P2M entries to point >>> to scratch page for PV guests. In 24f69373e2 ("xen/balloon: don't alloc >>> page while non-preemptible", kmap_flush_unused was moved after the >>> update for P2M table. In that case for 32 bit PV guest we might end up >>> with >>> >>> P2M X -----> scratch_page >>> M2P Y -----> X (Y is mfn in unused kmap entry) >>> >>> When PVMMU is consulted, it gets confused and returns the wrong value. >>> Eventually the guest crashes. >>> >>> Move the flush before __set_phys_to_machine to fix this. >> >> The scrub_page() will immediately repopulate the kmap cache with the MFN >> about to be returned to Xen so this isn't the correct place. >> > > If XEN_SCRUB_PAGE is not set then scrub_page is a nop. Even if > XEN_SCRUB_PAGE is set, the call to clear_highpage affects per-cpu kmap > not persisten kmap. kmap_flush_unused affects persistent kmap. > >> I don't understand your description of the problem so I cannot suggest a >> correct fix. What's consulting what? >> > > kmap_flush_unused consults PVMMU. It goes through all global kmap slots > and try to clear those unused ones. It calls flush_all_zero_pkmaps which > calls pte_page, which eventually goes to PVMMU. Ok, that's a real bug then. The P2M cannot be changed if there are still mappings for that PFN. David