WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: John Levon <levon@xxxxxxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] 3.1/2 live migration panic
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 16 Jan 2008 21:43:41 +0000
Delivery-date: Wed, 16 Jan 2008 13:44:03 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080116203719.GB15455@xxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchYiNwCGqrYPsR8EdyOUgAWy6hiGQ==
Thread-topic: [Xen-devel] 3.1/2 live migration panic
User-agent: Microsoft-Entourage/11.3.6.070618
If you have a debug build of Xen then the backtrace should be trustworthy.
Are there addresses in the backtrace that don't look to be within Xen text?
Your backtraces don't appear to be in the usual Xen format, so I'm not
entirely sure what I'm looking at.

 -- Keir

On 16/1/08 20:37, "John Levon" <levon@xxxxxxxxxxxxxxxxx> wrote:

> 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



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