On Wed, Dec 2, 2015 at 1:34 PM, Andrew Cooper <andrew.coop...@citrix.com>
wrote:

> 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>
> 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> 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@lists.xen.org
http://lists.xen.org/xen-devel

Reply via email to