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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] 3.1/2 live migration panic
From: John Levon <levon@xxxxxxxxxxxxxxxxx>
Date: Thu, 17 Jan 2008 02:42:48 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Delivery-date: Wed, 16 Jan 2008 18:43:28 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3B43D41.124CA%Keir.Fraser@xxxxxxxxxxxx>
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>
References: <20080116223718.GA29291@xxxxxxxxxxxxxxxxxxxxxxx> <C3B43D41.124CA%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
On Wed, Jan 16, 2008 at 11:01:21PM +0000, Keir Fraser wrote:

> Well that's a lot saner even without being a debug build. Possibly Tim has

Right, I added something to dig out the pending serial console buffer:

> ::serlog
.1.2-xvm  x86_64  debug=y  Not tainted ]----
(XEN) CPU:    3
(XEN) RIP:    e008:[<ffff828c801b4848>] shadow_get_and_create_l1e+0x47/0x32f
(XEN) RFLAGS: 0000000000010286   CONTEXT: hypervisor
(XEN) rax: ffff81c0ffc07c48   rbx: ffff8300e2e86100   rcx: 0000000000000000
(XEN) rdx: ffff8300e2ef7dd8   rsi: ffff8300e2ef7ad0   rdi: 00000000001d2cab
(XEN) rbp: ffff8300e2ef7c58   rsp: ffff8300e2ef7bf8   r8:  0000000000000006
(XEN) r9:  0000000000000006   r10: ffff8300e2edc100   r11: ffffff00f683e540
(XEN) r12: ffffff00b96fa858   r13: ffffff00b96f8050   r14: ffffff01f12d1e20
(XEN) r15: ffffff0105d8b980   cr0: 000000008005003b   cr4: 00000000000006f0
(XEN) cr3: 00000001cc4c1000   cr2: ffff81c0ffc07c48
(XEN) ds: 004b   es: 004b   fs: 0000   gs: 01c3   ss: 0000   cs: e008
(XEN) Xen stack trace from rsp=ffff8300e2ef7bf8:
(XEN)    ffff828404e45778 0000000000000000 00000000001f4efc
(XEN)    0000000000000050 0000000000000002 ffff81c0ffc07c48
(XEN)    00000000001d2cab ffff8300e2e87280 00000006e2e20100
(XEN)    ffff8300e2ef7da8 ffff8300e2ef7dd8 ffff8300e2edc100
(XEN)    ffff8300e2ef7e58 ffff828c801b68e8 0000000000000000
(XEN)    ffff8300e2e2ac38 ffff8301bc91ffc0 00000000001bc91f
(XEN)    0000000000071916 ffff8300e2ef7d98 0000000000000006
(XEN)    0000000100000006 ffff8300e2ef7d18 ffff828c8014e1fa
(XEN)    0000000498000004 ffff830000000008 000000040076ddc8
(XEN)    00000006a0000005 0000000100000000 0000000100000008
(XEN)    0000000098000004 ffff8300e2ef7f28 ffff8300e2ef7d38
(XEN)    ffff8300e2ef7f28 ffff8300e2ef7d48 0000000000000086
(XEN)    ffff828c80296838 000000038023d2a0 ffff8300e2ef7d48
(XEN)    ffff828c8015c5ef ffff828c80296838 ffff8300e2ef7f28
(XEN)    ffff8300e2ef7d68 ffff828c8015c5b9 00000002e2ef7d78
(XEN)    ffff828c8027c780 00007cff1d108267 ffff828c801464e1
(XEN)    ffffff00b5428008 0000000000000000 0000000000000008
(XEN)    ffff817f80f89690 ffff8300e2ef7e60 000000088027c780
(XEN)    0000000000000000 ffff8300e2ef7e58 0000000000094720
(XEN)    ffff828c8014e5f2 0000000000094720 0000002700000002
(XEN) Xen call trace:
(XEN)    [<ffff828c801b4848>] shadow_get_and_create_l1e+0x47/0x32f
(XEN)    [<ffff828c801b68e8>] sh_page_fault__shadow_4_guest_4+0x598/0xb9e
(XEN)    [<ffff828c80162fff>] paging_fault+0x3c/0x3e
(XEN)    [<ffff828c80162fa9>] fixup_page_fault+0x22b/0x245
(XEN)    [<ffff828c80163041>] do_page_fault+0x40/0x15c
(XEN)    
(XEN) Pagetable walk from ffff81c0ffc07c48:
(XEN)  L4[0x103] = 00000001cc4c1063 0000000000015d86
(XEN)  L3[0x103] = 00000001cc4c1063 0000000000015d86
(XEN)  L2[0x1fe] = 00000001a8d36067 0000000000015b61 
(XEN)  L1[0x007] = 0000000000000000 ffffffffffffffff

> shadow_get_and_create_l1e+0x47::dis
xpv`shadow_get_and_create_l1e+0x1a:     leaq   -0x30(%rbp),%rdx
xpv`shadow_get_and_create_l1e+0x1e:     movq   -0x10(%rbp),%rsi
xpv`shadow_get_and_create_l1e+0x22:     movq   -0x8(%rbp),%rdi
xpv`shadow_get_and_create_l1e+0x26:     call   -0x107   
<xpv`shadow_get_and_create_l2e>
xpv`shadow_get_and_create_l1e+0x2b:     movq   %rax,-0x38(%rbp)
xpv`shadow_get_and_create_l1e+0x2f:     cmpq   $0x0,-0x38(%rbp)
xpv`shadow_get_and_create_l1e+0x34:     jne    +0xd     
<xpv`shadow_get_and_create_l1e+0x43>
xpv`shadow_get_and_create_l1e+0x36:     movq   $0x0,-0x58(%rbp)
xpv`shadow_get_and_create_l1e+0x3e:     jmp    +0x2df   
<xpv`shadow_get_and_create_l1e+0x322>
xpv`shadow_get_and_create_l1e+0x43:     movq   -0x38(%rbp),%rax
xpv`shadow_get_and_create_l1e+0x47:     movq   (%rax),%rdi
xpv`shadow_get_and_create_l1e+0x4a:     call   -0x8f3   
<xpv`shadow_l2e_get_flags>
xpv`shadow_get_and_create_l1e+0x4f:     andl   $0x1,%eax
xpv`shadow_get_and_create_l1e+0x52:     testl  %eax,%eax
xpv`shadow_get_and_create_l1e+0x54:     je     +0x96    
<xpv`shadow_get_and_create_l1e+0xf0>
xpv`shadow_get_and_create_l1e+0x5a:     cmpl   $0x6,-0x1c(%rbp)
xpv`shadow_get_and_create_l1e+0x5e:     jne    +0x3d    
<xpv`shadow_get_and_create_l1e+0x9d>
xpv`shadow_get_and_create_l1e+0x60:     movq   -0x10(%rbp),%rax
xpv`shadow_get_and_create_l1e+0x64:     movq   0x8(%rax),%rax
xpv`shadow_get_and_create_l1e+0x68:     movl   (%rax),%edi
xpv`shadow_get_and_create_l1e+0x6a:     call   -0x1f1b  
<xpv`guest_l2e_get_flags>

(I'm back on 3.1 bits here)

1894     sl2e = shadow_get_and_create_l2e(v, gw, &sl2mfn, ft);
1895     if ( sl2e == NULL ) return NULL;
1896     /* Install the sl1 in the l2e if it wasn't there or if we need to
1897      * re-do it to fix a PSE dirty bit. */
1898     if ( shadow_l2e_get_flags(*sl2e) & _PAGE_PRESENT

So sl2e is non-zero, but bogus:

> ffff81c0ffc07c48::dump
                    0 1 2 3  4 5 6 7 \/ 9 a b  c d e f  01234567v9abcdef
mdb: failed to read data at 0xffff81c0ffc07c48: no mapping for address

This pointer is a constant though (right?)

regards
john

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