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

[Xen-devel] [PATCH] Fix OOS on domain crash.



Hello,

I couldn't reproduce the Nevada crash on my testbox, but this should fix the first Xen crash that was seen in the Nevada HVM (bugzilla #1322).

What I think most probably happened there is that the set_l2e call in shadow_get_and_create_l1e() has tried to resync a page, but somehow we weren't unable to remove the shadow (the real bug we should actually look after). sh_resync() then removes the page from the OOS hash and later in the page fault path we find the gw.l1mfn to be still OOS, so we try to update the snapshot and the bug happens.

Attached patch should fix this and other unlikely (like sh_unsync() failing to remove for hash collision the current gw.l1mfn) cases.

Gianluca

Signed-off-by: Gianluca Guida <gianluca.guida@xxxxxxxxxxxxx>
diff -r b75f0b3e2a7e xen/arch/x86/mm/shadow/multi.c
--- a/xen/arch/x86/mm/shadow/multi.c    Wed Aug 13 11:09:46 2008 +0100
+++ b/xen/arch/x86/mm/shadow/multi.c    Wed Aug 13 14:05:57 2008 -0400
@@ -3290,6 +3290,16 @@ static int sh_page_fault(struct vcpu *v,
     if ( sh_mfn_is_a_page_table(gmfn)
          && ft == ft_demand_write )
         sh_unsync(v, gmfn);
+
+    if ( unlikely(d->is_shutting_down) )
+    {
+        /* We might end up with a crashed domain here if
+         * sh_remove_shadows() in a previous sh_resync() call has
+         * failed. We cannot safely continue since some page is still
+         * OOS but not in the hash table anymore. */
+        shadow_unlock(d);
+        return 0;
+    }
 #endif /* OOS */
 
     /* Calculate the shadow entry and write it */
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

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