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

RE: [Xen-devel] [PATCH][SPT][DISCUSS] BUG() in shadow.h delete_shadow_status() with HVM guest


  • To: "Woller, Thomas" <thomas.woller@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Nakajima, Jun" <jun.nakajima@xxxxxxxxx>
  • Date: Tue, 9 May 2006 13:43:08 -0700
  • Delivery-date: Tue, 09 May 2006 13:43:48 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcZzldcJdz7SebjeQ1OGHswZcegpxQABcXPQ
  • Thread-topic: [Xen-devel] [PATCH][SPT][DISCUSS] BUG() in shadow.h delete_shadow_status() with HVM guest

Tom, hi

Thanks for the debugging.

Woller, Thomas wrote:
> We are hitting the BUG() at the end of delete_shadow_status() in
> xen/include/asm-x86/shadow.h with a PAE enabled 32bit unmodified
> windows guest, on both SVM and VMX, with a 64bit hypervisor.  After a
> PAE 32bit winxpsp2 or win2003 guest, boots, and then has been
> properly shutdown - performing a "xm destroy/xm shutdown" results in
> this BUG(). 
> 
> We clearly don't understand the intricacies of the SPT code, but our
> best guess seems to be that the BUG() is not valid in the failing
> case. 
> 
> The theory is that since a single PDPT page can have multiple PDPs,
> then maybe this function has already been called for this particular
> gmfn. Took the same philosophy as with free_shadow_page() in
> shadow_public.c line 766ish.

I think this is a bit different because the hash key has the index of
the PDP for PAE guests. I guess somehow tlbflush_timestamp has been
modified. Can you try this patch?

diff -r 1e3977e029fd xen/arch/x86/shadow.c
--- a/xen/arch/x86/shadow.c     Mon May  8 18:21:41 2006
+++ b/xen/arch/x86/shadow.c     Tue May  9 13:20:33 2006
@@ -3467,7 +3467,9 @@
         } else {
             printk("For non HVM shadow, create_l1_shadow:%d\n",
create_l2_shadow);
         }
-         shadow_update_min_max(l4e_get_pfn(sl4e), l3_table_offset(va));
+         
+        if ( v->domain->arch.ops->guest_paging_levels == PAGING_L4 )
+            shadow_update_min_max(l4e_get_pfn(sl4e),
l3_table_offset(va));
 
     }

But the second check !mfn_is_page_table(gmfn) is interesting. So I guess
the gmfn is shadowed as a different level, i.e. a linear page table is
used. 

> 
> We are definitely unsure as to the viability of this fix as a final
> solution, but the below fix alleviates this BUG() on both SVM and VMX
> boxes.  If anyone knowledgable in the SPT area could take a look at
> the patch, we'd appreciate your thoughts.
> thanks
> Tom
> 
> 
> # HG changeset patch
> # User twoller@xxxxxxxxxxxxxxxx
> # Node ID c8e01ad41814e923c70e97877a22ae6ffeacb30a
> # Parent  6e35b42994944e82550da99d03bcf9676b4ddec2
> Fix a problem when destroying windows domains that are PAE enabled.
> 
> diff -r 6e35b4299494 -r c8e01ad41814 xen/include/asm-x86/shadow.h
> --- a/xen/include/asm-x86/shadow.h    Mon May  8 17:44:46 2006
> +++ b/xen/include/asm-x86/shadow.h    Tue May  9 15:40:35 2006
> @@ -1352,6 +1352,17 @@
>      }
>      while ( x != NULL );
> 
> +#if CONFIG_PAGING_LEVELS == 4
> +    /*
> +     * Since a single PDPT page can have multiple PDPs, it's possible
> +     * that it has been already called for this gmfn.
> +     */
> +    if ( stype == PGT_l4_shadow && (!mfn_is_page_table(gmfn)) )
> +    {
> +        goto found;
> +    }
> +#endif
> +
>      /* If we got here, it wasn't in the list! */
>      BUG();
> 

Jun
---
Intel Open Source Technology Center

_______________________________________________
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®.