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

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Mon, Feb 13, 2012 at 05:37:38PM +0100, Manuel Bouyer wrote:
> All errors are of the same type, and looks similar to what you've
> reported first. It means we're trying to use a page as a page table
> which is already mapped read/write. So it's not the same problem
> as the bug I corrected (I should have checked more carefully), where
> Xen was telling me that a domU is trying to map read/write a page
> already used as page table (so it's the opposite !).
> 
> Today I ran into the issue you're describing now. So the patch I
> proposed is correct and fixes an issue; but it's not this one ...

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

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--