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: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: gnats-admin%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost, 
riz%NetBSD.org@localhost
Subject: Re: port-xen/45975 (panic: HYPERVISOR_mmu_update failed, ret: -22
 during heavy activity)
Date: Fri, 17 Feb 2012 13:12:46 +0100

 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
 --
 


Home | Main Index | Thread Index | Old Index