Re: [Xen-devel] 3.1/2 live migration panic

[John Levon <levon@xxxxxxxxxxxxxxxxx>]

On Wed, Jan 16, 2008 at 01:18:53AM +0000, John Levon wrote:

> ffff8300e2ef7c58 xpv:sh_page_fault__shadow_4_guest_4+598

Looking at what I can of the disasm, this looks like we're here:

2817     /* Make sure there is enough free shadow memory to build a chain of
2818      * shadow tables: one SHADOW_MAX_ORDER chunk will always be enough
2819      * to allocate all we need.  (We never allocate a top-level shadow
2820      * on this path, only a 32b l1, pae l2+1 or 64b l3+2+1) */
2821     shadow_prealloc(d, SHADOW_MAX_ORDER);
2822 
2823     /* Acquire the shadow.  This must happen before we figure out the 
rights 
2824      * for the shadow entry, since we might promote a page here. */
2825     ptr_sl1e = shadow_get_and_create_l1e(v, &gw, &sl1mfn, ft);
  >----<

So we're taking a fault somewhere in shadow_get_and_create_l1e(). Unfortunately 
the
exact point doesn't look easy to find, since the stack trace makes no sense:

ffff8300e2ef7b38 xpv`do_page_fault+0x13d(ffff8300e2ef7b48)
ffff8300e2ef7b68 0xffff828c801d354b()
ffff8300e2ef7c58 0xffff8300e2e86100()
ffff8300e2ef7e58 xpv`sh_page_fault__shadow_4_guest_4+0x598()

Looking through the stack by hand, I do see:

> ffff828c8014e5f2=p
                xpv`guest_get_eff_l1e+0xb9

but of course this might just be stack junk.

regardsjohn

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