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

[Xen-changelog] >I'm hitting an ASSERT in alloc_monitor_pagetable() with debug=y and I



# HG changeset patch
# User kaf24@xxxxxxxxxxxxxxxxxxxx
# Node ID ae2e13795c639a450ba2133ed7759da9bdffb170
# Parent  305649f5ad568e9fbb51aa69659a724a6dde75f3
>I'm hitting an ASSERT in alloc_monitor_pagetable() with debug=y and I
>can reproduce the condition when debug isn't on. The monitor_table is
>not zeroed when entering alloc_monitor_pagetable() - this happens when I
>create a vmx guest. I'm not sure why this happening at first glance.
>File: xen/arch/x86/shadow32.c
>Line: 689
>System: VT/VMX FC3 x86_32 (I can reproduce on FC4 x86_64 too)
>ASSERT(pagetable_get_paddr(v->arch.monitor_table) == 0);

Solution:
What happens is that the monitor page table is not zeroed out
during the initial setup for VMX guests.  As a result, at a later
time when we enable shadow mode for these VMX guests, we trip on
the ASSERT problem above.  To fix this, we just need to initialize
the monitor page table to 0 before calling vmx_final_setup_guest()
and enabling shadow mode.

diff -r 305649f5ad56 -r ae2e13795c63 xen/arch/x86/domain.c
--- a/xen/arch/x86/domain.c     Tue Nov  1 16:49:19 2005
+++ b/xen/arch/x86/domain.c     Tue Nov  1 18:13:06 2005
@@ -408,6 +408,9 @@
         if ( !pagetable_get_paddr(d->arch.phys_table) )
             d->arch.phys_table = v->arch.guest_table;
 
+        /* Initialize monitor page table */
+        v->arch.monitor_table = mk_pagetable(0);
+
         vmx_final_setup_guest(v);
     }
 

_______________________________________________
Xen-changelog mailing list
Xen-changelog@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-changelog


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.