Xen project Mailing List

Re: [Xen-devel] EFI GetNextVariableName crashes when running under Xen, but not under Linux. efi-rs=0 works. No memmap issues

To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>

From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>

Date: Mon, 26 Jan 2015 12:28:21 -0500

Cc: daniel.kiper@xxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, jbeulich@xxxxxxxx

Delivery-date: Mon, 26 Jan 2015 17:28:58 +0000

List-id: Xen developer discussion <xen-devel.lists.xen.org>

On Mon, Jan 26, 2015 at 04:36:03PM +0000, Andrew Cooper wrote: > On 26/01/15 16:27, Konrad Rzeszutek Wilk wrote: > > Hey Jan, Andrew, > > > > I am hoping you can help me in directing me where I ought to go next > > in debugging this. > > > > This is a Lenovo Thinkpad x230 with the latest BIOS and Xen 4.6 (todays > > 'staging' + my patches). Initially when I installed Xen the first time > > it would hang when loading the efi_vars module in Linux. Debugging > > a bit more and I found out that the issue is that we crash when > > calling GetNextVariableName (works fine with GetTime/SetTime, hand't > > tried GetVariable). > > > > I decided to implement in the hypervisor a little loop that would > > call GetNextVariableName and it works on my ASUS M5A87 board nicely. > > (attached at the bottom for comparison) > > > > However on this laptop it keeps on crashing. I've also added > > a bit of code to get the binary code from the GetNextVariableName > > to see if it looks legit - and it looks OK (obviously different > > from what the ASUS has implemented). > > > > Anyhow I am bit stuck: > > 1) It works with Linux, so what is it that Linux does that > > Xen does not? > > > > 2). I can't make sense of the stack trace. > > The efi firmware doesn't use frame pointers, but Xen does, which causes > its stack tracing to get confused. This is on my todo list to fix since > the last stack trace you submitted. > > You could see about creating a debug xen with frame_pointer=n during the > build, which will cause Xen to use the non-frame pointer aware stack > trace algorithm. > > That would help analyse the issue. Got a bit further. See for fun my inline comments. (XEN) 1:----[ Xen-4.6-unstable x86_64 debug=n Not tainted ]---- (XEN) CPU: 0 (XEN) RIP: e008:[<000000000000000f>] 000000000000000f (XEN) RFLAGS: 0000000000010207 CONTEXT: hypervisor (XEN) rax: 00000000cfdba230 rbx: ffff830216b3aa00 rcx: 000000000000001f (XEN) rdx: 00000000d6995ed0 rsi: 0000000000150670 rdi: ffff830216b3aa00 (XEN) rbp: ffff82d080457de8 rsp: ffff82d080457d50 r8: ffff82d080457df0 (XEN) r9: 0000000000008000 r10: ffff82d080457c5c r11: 00000000db002700 (XEN) r12: ffff82d080457df0 r13: 0000000000000000 r14: 0000000000000000 (XEN) r15: 00000000d1079000 cr0: 0000000080050033 cr4: 00000000001506f0 (XEN) cr3: 0000000216b3d000 cr2: 0000000000000000 (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: 0000 cs: e008 (XEN) Xen stack trace from rsp=ffff82d080457d50: (XEN) 0000000068f00002 00000000d6994d77 ffff82d080498b30 0000000000000206 (XEN) 00000000d1079000 ffff830216b39080 ffff830216b3a580 ffff82d080457df8 (XEN) 0000000216b3d000 ffff82d080229c7a ffff830216b3aa00 ffff830216b39080 (XEN) 0000000000150670 ffff82d080229c4a 0000000000000002 0000000100000008 (XEN) ffff82d080457df0 ffff82d080457de8 ffff82d080269c00 0000000000000400 (XEN) ffff82d080457e40 ffff82d080457e00 0000000000000003 ffff830216b4a4f0 (XEN) 0000000000000002 0000000000000008 0000000000000003 ffff8300d124b000 (XEN) ffff82d080269c00 ffff82d0804259b6 ffff8300d124b000 ffff8300d124afa0 (XEN) 00007d2f00000002 ffff8300d123abe5 00000000012b0000 000000021ab35000 (XEN) 0000000000000000 00000000ffffffff 000000000021e600 0000000000000000 (XEN) 00000000d124afa0 ffffffd080499780 0000000000499780 00000000012b0fff (XEN) 0000000000100000 0058bf9000000000 0000000800000000 000000010000006e (XEN) 0000000000000003 00000000000002f8 0000000000000000 00000000d123a240 (XEN) 00000000d0793408 00000000d0eff3e8 0000000000057000 00000000fed20000 (XEN) 0000000000002960 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) 0000000000000000 0000000000000000 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<000000000000000f>] 000000000000000f (XEN) [<ffff82d080229c7a>] efi_debug+0x24a/0x3c0 (XEN) [<ffff82d080229c4a>] efi_debug+0x21a/0x3c0 (XEN) [<ffff82d0804259b6>] __start_xen+0x25b6/0x3bc0 (XEN) Which is: 0x5a6 <efi_debug+550>: mov 0x0(%rip),%rax # 0x5ad <efi_debug+557> 0x5ad <efi_debug+557>: movq $0x400,0x28(%rsp) 0x5b6 <efi_debug+566>: sub $0x20,%rsp 0x5ba <efi_debug+570>: mov 0x30(%rsp),%r8 0x5bf <efi_debug+575>: mov 0x38(%rsp),%rcx 0x5c4 <efi_debug+580>: mov %rbx,%rdx 0x5c7 <efi_debug+583>: callq *0x50(%rax) 0x5ca <efi_debug+586>: add $0x20,%rsp (0x24a = 586 in decimal) And this is the EFI code: 0: 48 89 5c 24 08 mov %rbx,0x8(%rsp) 5: 48 89 6c 24 10 mov %rbp,0x10(%rsp) a: 48 89 74 24 18 mov %rsi,0x18(%rsp) f: 57 push %rdi 10: 41 54 push %r12 12: 41 55 push %r13 14: 48 83 ec 20 sub $0x20,%rsp 18: 45 33 ed xor %r13d,%r13d 1b: 48 85 c9 test %rcx,%rcx 1e: 4d 8b e0 mov %r8,%r12 [From above r8 is ffff82d080457df0, and r12 = ffff82d080457df0 so it gets past here] 21: 48 8b fa mov %rdx,%rdi 24: 48 8b e9 mov %rcx,%rbp 27: 0f 84 09 01 00 00 je 0x136 2d: 48 85 d2 test %rdx,%rdx 30: 0f 84 00 01 00 00 je 0x136 36: 4d 85 c0 test %r8,%r8 39: 0f 84 f7 00 00 00 je 0x136 [if anything is wrong @136 is the reutnr of EFI_INVALID_PARAMETER] 3f: 48 8b 05 76 11 00 00 mov 0x1176(%rip),%rax # 0x11bc 46: 48 8d 15 af 11 00 00 lea 0x11af(%rip),%rdx # 0x11fc Looks like I need to ingest in my debug code more code to cover 0x11bc and further. 4d: 48 8b c8 mov %rax,%rcx [so if rax has 00000000cfdba230, rcx should have the same, but it looks to be 000000000000001f, so perhaps we crashed in the 'lea' code? Or we ended up trying to execute below and in there we blew up?] 50: ff 50 20 callq *0x20(%rax) [Especially as we seem to pick some structure and call that, rax has 00000000cfdba230 so perhaps that is where we call, however the memmap has: (XEN) 00000cfdba000-00000cfdcffff type=4 attr=000000000000000f (XEN) .. skipped! (XEN) 00000cfdd0000-00000cffd1fff type=0 attr=000000000000000f (XEN) .. skipped! and Linux has: [ 0.000000] efi: mem22: [Boot Data | | | | | |WB|WT|WC|UC] range=[0x00000000cfdba000-0x00000000cfdd0000) (0MB) 53: 80 3d a2 11 00 00 01 cmpb $0x1,0x11a2(%rip) # 0x11fc 5a: 75 1b jne 0x77 5c: 48 8b 05 81 11 00 00 mov 0x1181(%rip),%rax # 0x11e4 63: 4d 8b c4 mov %r12,%r8 66: 48 8b d7 mov %rdi,%rdx 69: 48 8b cd mov %rbp,%rcx 6c: ff 50 08 callq *0x8(%rax) 6f: 48 8b d8 mov %rax,%rbx 72: e9 ba 00 00 00 jmpq 0x131 77: 48 8b cf mov %rdi,%rcx 7a: e8 bd 0f 00 00 callq 0x103c 7f: 48 3d 00 01 00 00 cmp $0x100,%rax 85: 0f 87 ab 00 00 00 ja 0x136 8b: 44 38 2d c2 10 00 00 cmp %r13b,0x10c2(%rip) # 0x1154 92: 75 12 jne 0xa6 94: 48 8b 05 d1 10 00 00 mov 0x10d1(%rip),%rax # 0x116c 9b: b9 1f 00 00 00 mov $0x1f,%ecx ... 136: 48 b8 02 00 00 00 00 movabs $0x8000000000000002,%rax 13d: 00 00 80 140: 48 8b 5c 24 40 mov 0x40(%rsp),%rbx 145: 48 8b 6c 24 48 mov 0x48(%rsp),%rbp 14a: 48 8b 74 24 50 mov 0x50(%rsp),%rsi 14f: 48 83 c4 20 add $0x20,%rsp 153: 41 5d pop %r13 155: 41 5c pop %r12 157: 5f pop %rdi 158: c3 retq 159: cc int3 15a: cc int3 15b: cc int3 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel

©2013 Xen Project, A Linux Foundation Collaborative Project. All Rights Reserved.
Linux Foundation is a registered trademark of The Linux Foundation.
Xen Project is a trademark of The Linux Foundation.