On 02/12/15 18:21, Tamas K Lengyel wrote: > > > On Tue, Dec 1, 2015 at 5:40 AM, Andrew Cooper > <andrew.coop...@citrix.com <mailto:andrew.coop...@citrix.com>> wrote: > > On 01/12/15 01:21, Tamas K Lengyel wrote: >> >> >> On Mon, Nov 30, 2015 at 7:01 PM, Razvan Cojocaru >> <rcojoc...@bitdefender.com <mailto:rcojoc...@bitdefender.com>> wrote: >> >> On 12/01/2015 01:32 AM, Tamas K Lengyel wrote: >> > Hi all, >> > I'm trying to extend the current vm_event system to be able >> to emulate >> > over an in-guest breakpoint using the >> VM_EVENT_FLAG_SET_EMUL_READ_DATA >> > feature. The idea is to have the vm_event listener send >> back the >> > contents of the memory that was overwritten by the breakpoint >> > instruction, have Xen emulate one instruction, and resume >> execution >> > normally afterwards. This would eliminate the need of >> removing the >> > breakpoint, singlestepping, and placing the breakpoint back >> again. >> > >> > Unfortunately I encounter this crash when I call >> > hvm_mem_access_emulate_one in the event response handler: >> > >> > (XEN) vm_event.c:72:d0v0 Checking flags on int3 response 37 >> > (XEN) Xen BUG at >> /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372 >> > > This BUG() is the cause of the crash. > > It is a bad parameter to VMREAD, by the looks of it. > > ~Andrew > > > So this is quite confusing. The error seems to stem from > (XEN) [<ffff82d0801d557e>] hvm_emulate_prepare+0x23/0x6c > > in the line > hvmemul_ctxt->intr_shadow = hvm_funcs.get_interrupt_shadow(current); > > which is effectively a simple > __vmread(GUEST_INTERRUPTIBILITY_INFO, &intr_shadow); > > My printk after this doesn't show up in the console so this must be > where the bug triggers. > > (XEN) emulate.c:1828:d1v0 get interrupt shadow > (XEN) emulate.c:1830:d1v0 get interrupt shadow done > (XEN) emulate.c:1836:d1v0 get seg cs > (XEN) emulate.c:1838:d1v0 get seg ss > (XEN) vm_event.c:72:d0v0 Checking flags on int3 response 37 > (XEN) emulate.c:1828:d0v0 get interrupt shadow > (XEN) Xen BUG at /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372 > (XEN) ----[ Xen-4.7-unstable x86_64 debug=y Tainted: C ]---- > (XEN) CPU: 0 > (XEN) RIP: e008:[<ffff82d080202e00>] vmx_vmenter_helper+0x3d/0x1cd > (XEN) RFLAGS: 0000000000010203 CONTEXT: hypervisor (d0v0) > (XEN) rax: 0000000000004824 rbx: ffff8300ae30fb68 rcx: > 0000000000000000 > (XEN) rdx: ffff8300ae308000 rsi: 000000000000000a rdi: > ffff8300ae550000 > (XEN) rbp: ffff8300ae30fb28 rsp: ffff8300ae30fb28 r8: > ffff830430de0000 > (XEN) r9: 0000000000000004 r10: 0000000000000004 r11: > 0000000000000001 > (XEN) r12: ffff8300ae308000 r13: ffff8300ae30ff18 r14: > ffff8300ae0f8000 > (XEN) r15: ffff82d08028a480 cr0: 0000000080050033 cr4: > 00000000000426e0 > (XEN) cr3: 000000043df79000 cr2: 00007f761d656000 > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 > (XEN) Xen stack trace from rsp=ffff8300ae30fb28: > (XEN) ffff8300ae30fb58 ffff82d0801d55ab 00007cff51cf0497 > 0000000000000006 > (XEN) 00000000ffffffff 0000000000000002 ffff8300ae30fc98 > ffff82d0801d5776 > (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) 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000048 > ffff8300ae30fcd0 > (XEN) ffff8300ae30fcd0 ffff830412da0c50 ffff8300ae30fcb8 > ffff82d0801c02c1 > (XEN) ffff8300ae30fcd0 ffff83040fbaf000 ffff8300ae30fe38 > ffff82d08013a483 > (XEN) 00007cff51cf0307 0000002500000001 0000000000000006 > 0000000000000000 > (XEN) 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > (XEN) c214c48300000008 0000000064900010 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) [<ffff82d080202e00>] vmx_vmenter_helper+0x3d/0x1cd > (XEN) [<ffff82d0801d55ab>] hvm_emulate_prepare+0x50/0x10e > (XEN) [<ffff82d0801d5776>] hvm_mem_access_emulate_one+0x49/0xd3 > (XEN) [<ffff82d0801c02c1>] vm_event_interrupt_emulate_check+0x5c/0x63 > (XEN) [<ffff82d08013a483>] vm_event_resume+0xa1/0x131 > (XEN) [<ffff82d08013a914>] vm_event.c#monitor_notification+0x25/0x28 > (XEN) [<ffff82d080108554>] evtchn_send+0x126/0x17e > (XEN) [<ffff82d080109a74>] do_event_channel_op+0xe66/0x14be > (XEN) [<ffff82d08024d992>] lstar_enter+0xe2/0x13c > (XEN) > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 0: > (XEN) Xen BUG at /share/src/xen/xen/include/asm/hvm/vmx/vmx.h:372 > > Why would that vmread fail there and why would the call trace tell me > it's in vmx_vmenter_helper?
The symbol information is incorrect because of the bugframe being inside an UNLIKELY() block. I have a patch to fix it, http://www.gossamer-threads.com/lists/xen/devel/404482?do=post_view_threaded but this has been rejected. I don't see a way to make a global symbol for the current translation units' unlikely section. I also don't believe it is a sensible approach to take even if is a technical way to make it happen, as it still leaves the stack trace not correctly identifying the source of the issue, so the fix is in limbo. ~Andrew
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
