[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Trap flags, debug and emulation - xen 4.1.1



On Tue, Oct 11, 2011 at 1:56 PM, Tim Deegan <tim@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.