[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 <oster%cs.usask.ca@localhost>
To: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost,
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 <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
With this patch I was able to do a successful 'build.sh -j8' build on an
amd64 DOMU that was previously failing.
Main Index |
Thread Index |