Re: [Xen-devel] [PATCH] xen/balloon: flush unused mappings before updating P2M table

[Wei Liu <wei.liu2@xxxxxxxxxx>]

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.

But I just discover something new so this patch can be dropped for the
moment.

Wei.

> As an aside, I do think the flush_tlb_all() is unnecessary since Xen
> does that for us in the update_va_mapping hypercall.  I think. Tim, can
> you confirm?
> 
> David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel