[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





On Wed, Dec 2, 2015 at 1:34 PM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
On 02/12/15 18:21, Tamas K Lengyel wrote:


On Tue, Dec 1, 2015 at 5:40 AM, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
On 01/12/15 01:21, Tamas K Lengyel wrote:


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

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

I see, thanks for the explanation.

In the meanwhile I noticed that the vmread fails as it happens in the context of d0v0 instead of d1v1. Unfortunately the entire emulation code is pretty much hard-coded to use "current" everywhere so I'm not sure how I could make use of it here.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.