Re: [Xen-devel] Emulating in response of an int3 vm_event

[Tamas K Lengyel <tamas@xxxxxxxxxxxxx>]

On Mon, Nov 30, 2015 at 7:01 PM, Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx> 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
> (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.

Yeap, thanks, will try to sprinkle some debug info in there. It's very easy to reproduce as it crashes immediately on the first event.

Â

Is this code available somewhere, or is it maybe private code?

It's up on github at https://github.com/tklengyel/xen/compare/int_emul?expand=1. I'm hoping to send a patch for this in once I get it working.

Tamas

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel