On 02/12/15 18:38, Tamas K Lengyel wrote:
>
>
> On Wed, Dec 2, 2015 at 1:34 PM, Andrew Cooper
> <andrew.coop...@citrix.com <mailto: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 <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
>
>
> 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.
You will need to vmx_vmcs_{enter,exit}() to get the correct vmcs in context.
~Andrew
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
