Re: port-xen/45975 (panic: HYPERVISOR_mmu_update failed, ret: -22 during heavy activity)

[Greg Oster <oster%cs.usask.ca@localhost>]

On Fri, 17 Feb 2012 16:30:26 +0100
Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:

> On Fri, Feb 17, 2012 at 01:12:46PM +0100, Manuel Bouyer wrote:
> > I think I found where the problem comes from:
> > in uvm, uvm_km_pgremove_intrsafe() will return a page to the free
> > list. But as it uses pmap_extract(), the mapping of the pages in
> > pmap_kernel() is removed *after* calling uvm_km_pgremove_intrsafe().
> > So there is a window where pages are returned to the free list, but
> > are still mapped in pmap_kernel(); another CPU can allocate and map
> > this page in this time (remember a CPU can be preempted by the
> > hypervisor, so the window can be quite long).
> > I confirmed this by adding an (expensive) check in uvm_pagefree()
> > looking for existing mappings of a page.
> > Multiple mappings of the same physical page with different
> > attributes are not a problem on real hardware, so this is a problem
> > only for Xen.
> > One trivial fix is to call pmap_kremove() from
> > uvm_km_pgremove_intrsafe() just after pmap_extract() has been done
> > (and remove it from callers). I'm testing this now
> 
> See attached patch. I couldn't make my test domUs (a i386PAE with 4
> virtual CPU on a dual-core box, and a amd64 with 8 virtual CPUs on
> a 8-core box), several build.sh -j<as_appropriate> release have
> completed.

With this patch I was able to do a successful 'build.sh -j8' build on an
amd64 DOMU that was previously failing.

Later...

Greg Oster