[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Emulating in response of an int3 vm_event
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 > (XEN) ----[ Xen-4.7-unstable x86_64 debug=y Not tainted ]---- > (XEN) CPU: 0 > (XEN) RIP: e008:[<ffff82d080202e90>] vmx_vmenter_helper+0x16d/0x30d > (XEN) RFLAGS: 0000000000010203 CONTEXT: hypervisor (d0v0) > (XEN) rax: 0000000000004824 rbx: ffff8300ae30fb68 rcx: 0000000000000000 > (XEN) rdx: 00000000ffffffff rsi: ffff8300ae30ff18 rdi: ffff8300ae550000 > (XEN) rbp: ffff8300ae30fb38 rsp: ffff8300ae30fb38 r8: ffff830430de0000 > (XEN) r9: 0000000000000004 r10: 0000000000000004 r11: 0000000000000002 > (XEN) r12: ffff8300ae30ff18 r13: 0000000000000002 r14: ffff8300ae35f000 > (XEN) r15: ffff82d08028a448 cr0: 0000000080050033 cr4: 00000000000426e0 > (XEN) cr3: 000000040f750000 cr2: 00007f7550df2000 > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 > (XEN) Xen stack trace from rsp=ffff8300ae30fb38: > (XEN) ffff8300ae30fb58 ffff82d0801d557e 0000000000000006 00000000ffffffff > (XEN) ffff8300ae30fc98 ffff82d0801d56d4 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 0000000000000000 0000000000000000 > (XEN) 0000000000000048 ffff8300ae30fcd0 ffff8300ae30fcd0 ffff830135da1810 > (XEN) ffff8300ae30fcb8 ffff82d0801c02c1 ffff8300ae30fcd0 ffff830135da3000 > (XEN) ffff8300ae30fe38 ffff82d08013a483 000000000040f750 0000002500000001 > (XEN) 0000000000000006 0000000000000000 0000000000000000 0000000000000000 > (XEN) 0000000000000000 0000000000000000 c214c48300000008 0000000064900010 > (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) [<ffff82d080202e90>] vmx_vmenter_helper+0x16d/0x30d > (XEN) [<ffff82d0801d557e>] hvm_emulate_prepare+0x23/0x6c > (XEN) [<ffff82d0801d56d4>] hvm_mem_access_emulate_one+0x49/0xd5 > (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 > > From this trace I'm not actually sure what is causing the crash. If > someone has an idea, help would be much appreciated! I'm not sure what's causing the crash, but vmx_vmenter_helper() is a fairly short function so I'd suggest sprinkling a few printk()s and see which one is the first one to not show up before the stack trace, until you can pinpoint the exact place causing the crash. Either that, or try to disassemble the hypervisor binary and see what's at vmx_vmenter_helper+0x16d/0x30d, but I'd use the printk() method if this is easily reproduced. Is this code available somewhere, or is it maybe private code? Cheers, Razvan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |