Xen devel - Oct 2011 - Trap flags, debug and emulation - xen 4.1.1

Hi,

I''ve been trying a simple experiment on my intel box (along the lines
of http://web.archiveorange.com/archive/v/tXSRN8SPX0sXRutnvOCu). I
have a system with VMX but no EPT, it falls back on shadow page tables
and I disable super pages. The VM itself is a 32 bit OS. I am using
xen-4.1.1 on ubuntu.

Quoting from the link above

"First, I mark a guest page "not present" inside the shadow page
table
so that I could intercept any operation that involves this page. When
the guest tries to access that page, it faults and control goes to Xen
(sh_page_fault function). There, I emulate that operation and return
the control to guest to execute next instruction. I could get my first
part working.

In the second part after emulating the instruction inside Xen, I want
to perform single-step execution from next instruction onwards so that
I could monitor further execution of guest from that point.

To achieve that I did following: After emulating an instruction inside
Xen and before sending the control back to guest OS, I set the
EFLAGS''s trap bit set by doing following operation:

regs->eflag |= X86_EFLAGS_TF

And return the control from sh_page_fault function by saying "return
EFAULT_FIXED".

I am doing something very similar. I do get the fault and I can set
the trap, but I don''t see any form of single stepping take place as I
do not get the TRAP_debug exception back. My exception_bitmap has
TRAP_no_device, TRAP_page_fault, TRAP_debug and TRAP_int3 set.

I''ve tried debugging the issue with xentrace and printks, but sadly I
could not track down the issue. The CPU does have
cpu_has_monitor_trap_flag set to true.

Could anyone give me clues on how to track down why I did not get a
TRAP_debug exception via a VMEXIT?

Balbir Singh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi,

 I''ve been trying a simple experiment on my intel box (along the lines
 of http://web.archiveorange.com/archive/v/tXSRN8SPX0sXRutnvOCu). I
 have a system with VMX but no EPT, it falls back on shadow page tables
 and I disable super pages. The VM itself is a 32 bit OS. I am using
 xen-4.1.1 on ubuntu.

 Quoting from the link above

 "First, I mark a guest page "not present" inside the shadow page
table
 so that I could intercept any operation that involves this page. When
 the guest tries to access that page, it faults and control goes to Xen
 (sh_page_fault function). There, I emulate that operation and return
 the control to guest to execute next instruction. I could get my first
 part working.

 In the second part after emulating the instruction inside Xen, I want
 to perform single-step execution from next instruction onwards so that
 I could monitor further execution of guest from that point.

 To achieve that I did following: After emulating an instruction inside
 Xen and before sending the control back to guest OS, I set the
 EFLAGS''s trap bit set by doing following operation:

 regs->eflag |= X86_EFLAGS_TF

 And return the control from sh_page_fault function by saying "return
 EFAULT_FIXED".

 I am doing something very similar. I do get the fault and I can set
 the trap, but I don''t see any form of single stepping take place as I
 do not get the TRAP_debug exception back. My exception_bitmap has
 TRAP_no_device, TRAP_page_fault, TRAP_debug and TRAP_int3 set.

 I''ve tried debugging the issue with xentrace and printks, but sadly I
 could not track down the issue. The CPU does have
 cpu_has_monitor_trap_flag set to true.

 Could anyone give me clues on how to track down why I did not get a
 TRAP_debug exception via a VMEXIT?

 Balbir Singh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi, 

At 08:39 +0530 on 11 Oct (1318322368), Balbir Singh
wrote:
>  I am doing something very similar. I do get the fault and I can set
>  the trap, but I don''t see any form of single stepping take place
as I
>  do not get the TRAP_debug exception back. My exception_bitmap has
>  TRAP_no_device, TRAP_page_fault, TRAP_debug and TRAP_int3 set.
> 
>  I''ve tried debugging the issue with xentrace and printks, but
sadly I
>  could not track down the issue. The CPU does have
>  cpu_has_monitor_trap_flag set to true.
> 
>  Could anyone give me clues on how to track down why I did not get a
>  TRAP_debug exception via a VMEXIT?
It sounds like you''re doing the right thing - just a question of
looking
for the bug. :)  I would try checking for the TF flag as close as
possible to the vmenter (maybe even in the assembly - you could call out
to a special C function if it''s set), and for the debug vmexit right at
the
top of the vmexit handler to make sure that some other clever debugging
code isn''t consuming it.   Probably also worth double-chjecking that
nothing else ois overwriting the exception bitmap before the vmenter. 

Cheers,

Tim.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, Oct 11, 2011 at 1:56 PM, Tim Deegan <tim@xen.org>
wrote:
> Hi,
>
> At 08:39 +0530 on 11 Oct (1318322368), Balbir Singh wrote:
>>  I am doing something very similar. I do get the fault and I can set
>>  the trap, but I don''t see any form of single stepping take
place as I
>>  do not get the TRAP_debug exception back. My exception_bitmap has
>>  TRAP_no_device, TRAP_page_fault, TRAP_debug and TRAP_int3 set.
>>
>>  I''ve tried debugging the issue with xentrace and printks, but
sadly I
>>  could not track down the issue. The CPU does have
>>  cpu_has_monitor_trap_flag set to true.
>>
>>  Could anyone give me clues on how to track down why I did not get a
>>  TRAP_debug exception via a VMEXIT?
>
> It sounds like you''re doing the right thing - just a question of
looking
> for the bug. :)  I would try checking for the TF flag as close as
> possible to the vmenter (maybe even in the assembly - you could call out
> to a special C function if it''s set), and for the debug vmexit
right at the
> top of the vmexit handler to make sure that some other clever debugging
> code isn''t consuming it.   Probably also worth double-chjecking
that
> nothing else ois overwriting the exception bitmap before the vmenter.
>
Hi, Tim,

Thanks, I am taking the debugging to entry.S, I can see the flags
(UREGS_eflags) have the bit set on VMENTRY, but mostly disabled on
VMEXIT. I wonder if the guest operating system is playing with the
bit, I doubt it though. I''ll continue debugging

Balbir Singh

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel