NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

The following reply was made to PR port-xen/45975; it has been noted by GNATS.

From: Greg Oster <>
To: Manuel Bouyer <>
Subject: Re: port-xen/45975 (panic: HYPERVISOR_mmu_update failed, ret: -22
 during heavy activity)
Date: Fri, 17 Feb 2012 11:26:06 -0600

 On Fri, 17 Feb 2012 16:30:26 +0100
 Manuel Bouyer <> 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 -j<as_appropriate> release have
 > completed.
 With this patch I was able to do a successful ' -j8' build on an
 amd64 DOMU that was previously failing.
 Greg Oster

Home | Main Index | Thread Index | Old Index