|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [Xen-users] xc_hvm_inject_trap() failing for int3 traps under Xen 4.2.2
On 06/10/2013 12:36 PM, Tim Deegan wrote:
> At 16:57 +0000 on 10 Jun (1370883430), Antony Saba wrote:
>> On 06/10/2013 05:29 AM, George Dunlap wrote:
>>> On Fri, Jun 7, 2013 at 4:51 PM, Steven Maresca <steve@xxxxxxxxxxxx> wrote:
>>>> Tony,
>>>>
>>>> I can confirm INT3 re-injection does work on 4.2.x and 4.3, but the
>>>> problem you observed is certainly present.
>>>>
>>>> As suggested, it was necessary when invoking xc_hvm_inject_trap to
>>>> specify the 1-byte instruction length for 0xCC (without which the VM
>>>> was intentionally crashed by Xen).
>>>>
>>>> In this case, there's no need to inspect the actual instruction
>>>> referenced by the IP because it seems the trap is only fired for the
>>>> one-byte variant (0xCD03 of course works properly, but no event is
>>>> emitted).
>>>>
>>>> Mirroring your experience with 4.1.2, for my testing on 4.2+ the
>>>> return of xc_hvm_inject_trap is also always non-zero even for
>>>> successful re-injection..whether that's intended is another question.
>>>>
>>>> Steve
>>>>
>>>> NOTE: I would definitely consider it a bug that the xen-access.c
>>>> example crashes guests when attempting to use the INT3
>>>> mode...non-critical for most users, but nevertheless.
>>>
>>> I'm having a bit of trouble finding the conclusion here.
>>>
>>> So it seems the problem is that if a *guest* is doing int3
>>> instructions, that will interfere with the ability of the debugger to
>>> use int3 to do introspection -- is that right?
>>>
>> Yes, that is one scenario. The one I was experiencing was some
>> (apparently legitimate) background process on a Windows 7 x64 guest that
>> just always executes an int3 when it runs.
>>
>> I'll try to summarize, someone please correct me if I'm wrong. There
>> are 2 things going on here:
>>
>> 1) The patch previously posted by AP is the correct way to call
>> xc_hvm_inject_trap() for int 3 (0xcc). That is, the instruction_length
>> parameter must be set to 1.
>
> Not necessarily, AFAICT -- you'd need to fetch and decode the
> instruction in order to detect prefix bytes (other than LOCK, which is
> explicitly disallowed).
I just verified this again under 4.2.2, here is the crash dump from xl
dmesg:
(XEN) <vm_resume_fail> error code 7
(XEN) domain_crash_sync called from vmcs.c:1068
(XEN) Domain 2 (vcpu#0) crashed on cpu#6:
(XEN) ----[ Xen-4.2.2 x86_64 debug=n Not tainted ]----
(XEN) CPU: 6
(XEN) RIP: 001b:[<0000000000401000>]
(XEN) RFLAGS: 0000000000000246 CONTEXT: hvm guest
(XEN) rax: ffff82c4801053e2 rbx: ffff83017838e000 rcx: 000000007ffd4000
(XEN) rdx: ffff82c4801cc600 rsi: 0000000000000000 rdi: ffff82c4801d5b2d
(XEN) rbp: ffff82c480180a99 rsp: 000000000012ff7c r8: 000000000012ffc0
(XEN) r9: ffff8302334f7f18 r10: 0000000000000002 r11: ffff82c4801053bb
(XEN) r12: 0000000000000000 r13: 0000000000000000 r14: 0000000000000000
(XEN) r15: ffff8302334f7f18 cr0: 000000008001003b cr4: 00000000000006f9
(XEN) cr3: 000000000b600180 cr2: 0000000000153005
(XEN) ds: 0023 es: 0023 fs: 003b gs: 0000 ss: 0023 cs: 001b
This is the change to xen_access to ignore the error and attempt to
resume that causes it:
diff --git a/tools/tests/xen-access/xen-access.c
b/tools/tests/xen-access/xen-access.c
index 9ec7332..77d7b12 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -668,8 +668,8 @@ int main(int argc, char *argv[])
if (rc < 0)
{
ERROR("Error %d injecting int3\n", rc);
- interrupted = -1;
- continue;
+ //interrupted = -1;
+ //continue;
}
break;
>
>> 2) xc_hvm_inject_trap() always returns a negative value, even when there
>> is not a problem and the guest receives the trap as expected. There
>> hasn't been a clarification as to whether it's supposed to return
>> non-negative, but one would assume that it should because of the way the
>> xen-access.c example checks for it.
>
> That looks like a hypervisor bug to me: does this (untested) patch fix
> it for you?
>
> commit 67b9272fcedcb5dc73cc77a2adf580f2572117d7
> Author: Tim Deegan <tim@xxxxxxx>
> Date: Mon Jun 10 19:35:34 2013 +0100
>
> x86/hvm: Fix HVMOP_inject_trap return value on success.
>
> Reported-by: Antony Saba <Antony.Saba@xxxxxxxxxxxx>
> Signed-off-by: Tim Deegan <tim@xxxxxxx>
>
> diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
> index ce44bff..6c86fc2 100644
> --- a/xen/arch/x86/hvm/hvm.c
> +++ b/xen/arch/x86/hvm/hvm.c
> @@ -4430,6 +4430,7 @@ long do_hvm_op(unsigned long op,
> XEN_GUEST_HANDLE_PARAM(void) arg)
> v->arch.hvm_vcpu.inject_trap.error_code = tr.error_code;
> v->arch.hvm_vcpu.inject_trap.insn_len = tr.insn_len;
> v->arch.hvm_vcpu.inject_trap.cr2 = tr.cr2;
> + rc = 0;
> }
>
> param_fail8:
>
>
>
This works, but the instruction size must be set to 1, at least on 4.2.2
to work for me. Here is the patch against RELEASE-4.2.2.
diff --git a/tools/tests/xen-access/xen-access.c
b/tools/tests/xen-access/xen-access.c
index 9ec7332..8bcd88b 100644
--- a/tools/tests/xen-access/xen-access.c
+++ b/tools/tests/xen-access/xen-access.c
@@ -664,7 +664,7 @@ int main(int argc, char *argv[])
/* Reinject */
rc = xc_hvm_inject_trap(
xch, domain_id, req.vcpu_id, 3,
- HVMOP_TRAP_sw_exc, -1, 0, 0);
+ HVMOP_TRAP_sw_exc, -1, 1, 0);
if (rc < 0)
{
ERROR("Error %d injecting int3\n", rc);
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index 3d471a5..4c2320e 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -4372,6 +4372,7 @@ long do_hvm_op(unsigned long op,
XEN_GUEST_HANDLE(void) arg)
v->arch.hvm_vcpu.inject_trap.error_code = tr.error_code;
v->arch.hvm_vcpu.inject_trap.insn_len = tr.insn_len;
v->arch.hvm_vcpu.inject_trap.cr2 = tr.cr2;
+ rc = 0;
}
param_fail8:
--
Antony Saba, antony.saba@xxxxxxxxxxxx
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |