Re: [Xen-users] [Xen-devel] xc_hvm_inject_trap() failing for int3 traps under Xen 4.2.2

[Antony Saba <Antony.Saba@xxxxxxxxxxxx>]

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.

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.

There was an error in my modifications to xen-access.c to ignore the
error from xc_hvm_inject_trap(), which was causing resume_page() to not
get called, resulting in a frozen guest on my machines.  Thanks again
for the previous responses; I did get it working without freezing the guest.

> If anyone on this thread were able to make and test a proper fix, I'm
> sure we would all appreciate it. :-)
> 
> At this point it would definitely not be a release blocker, but we
> would obviously like to have it fixed.

-Tony

-- 
Antony Saba, antony.saba@xxxxxxxxxxxx
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users