Re: Xen BUG at mm-locks.h:118 in 4.2.1 - mm locking order violation - Dom0 reboot

[Tim Deegan <tim@xen.org>]

[-- Attachment #1: Type: text/plain, Size: 2288 bytes --]

Hi, 

Thanks for the report. 

At 11:47 +0100 on 18 Feb (1361188042), Sylvain Munaut wrote:
> I've just installed a self-built Xen 4.2.1 package on a debian wheezy
> and when trying to run a HVM VM (that I was previously running with
> the official xen 4.0 package on squeeze), it starts fine and I can
> even use the VM for a few minutes then suddenly I loose all
> communication with VM and the Dom0 and it just reboots ...

Did you make any changes to Xen before you built it, or were you just
building your own to get 4.2?

> (XEN) mm locking order violation: 260 > 222
> (XEN) Xen BUG at mm-locks.h:118

Hmm, taking the p2m lock with the pod lock held. :( My guess would be
the p2m_lock() in p2m_pod_emergency_sweep().

Do you by any chance have the xen-syms file from when you built Xen?
That would let us see exactly what's happened.

In the meantime, perhaps you could try the attached (untested) patch.
If my guess is right, it ought to stop the crashes but you might find
the VM's performance suffers.

Cheers,

Tim.

> (XEN)    [<ffff82c4801e15fd>] p2m_pod_demand_populate+0x87d/0x8a0
> (XEN)    [<ffff82c48016a4bd>] get_page+0x2d/0x100
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801dbec3>] p2m_gfn_to_mfn+0x693/0x810
> (XEN)    [<ffff82c4801d6666>] __get_gfn_type_access+0x86/0x260
> (XEN)    [<ffff82c4801fa23f>] sh_page_fault__guest_3+0x24f/0x1e40
> (XEN)    [<ffff82c4801cdda8>] vmx_update_guest_cr+0x78/0x5d0
> (XEN)    [<ffff82c4801ae2da>] hvm_set_cr0+0x2ea/0x480
> (XEN)    [<ffff82c4801b2bb4>] hvm_mov_to_cr+0xe4/0x1a0
> (XEN)    [<ffff82c4801cfa63>] vmx_vmexit_handler+0xd33/0x1790
> (XEN)    [<ffff82c4801cafb5>] vmx_do_resume+0xb5/0x170
> (XEN)    [<ffff82c48015968c>] context_switch+0x15c/0xdf0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c480125d7b>] add_entry+0x4b/0xb0
> (XEN)    [<ffff82c4801bf3c7>] pt_update_irq+0x27/0x200
> (XEN)    [<ffff82c480119830>] csched_tick+0x0/0x2e0
> (XEN)    [<ffff82c4801bd5a1>] vlapic_has_pending_irq+0x21/0x60
> (XEN)    [<ffff82c4801b5fca>] hvm_vcpu_has_pending_irq+0x4a/0x90
> (XEN)    [<ffff82c4801c85c4>] vmx_intr_assist+0x54/0x290
> (XEN)    [<ffff82c4801d2911>] nvmx_switch_guest+0x51/0x6c0
> (XEN)    [<ffff82c4801d4256>] vmx_asm_do_vmentry+0x0/0xea

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 794 bytes --]

diff -r 4efc7f87d749 xen/arch/x86/mm/p2m.c
--- a/xen/arch/x86/mm/p2m.c	Thu Feb 14 17:07:41 2013 +0000
+++ b/xen/arch/x86/mm/p2m.c	Mon Feb 18 11:32:44 2013 +0000
@@ -219,7 +219,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
     }
 
     /* For now only perform locking on hap domains */
-    if ( locked && (hap_enabled(p2m->domain)) )
+    if ( locked )
         /* Grab the lock here, don't release until put_gfn */
         gfn_lock(p2m, gfn, 0);
 
@@ -248,8 +248,7 @@ mfn_t __get_gfn_type_access(struct p2m_d
 
 void __put_gfn(struct p2m_domain *p2m, unsigned long gfn)
 {
-    if ( !p2m || !paging_mode_translate(p2m->domain) 
-              || !hap_enabled(p2m->domain) )
+    if ( !p2m || !paging_mode_translate(p2m->domain) )
         /* Nothing to do in this case */
         return;
 

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel