[Qemu-devel] Debugging on HAXM

[Qemu-devel] Debugging on HAXM

[Alexandro Sanchez Bach]

Hello,

 

A bit of context: I'm working on a QEMU fork adding support for PlayStation
4 hardware. It's still in development and debugging kernel drivers has
become everyday work. While TCG supports debugging, it cannot handle various
extensions like AVX/AVX2 that are extensively used by the guest applications
and performance has become quite a problem. This system is closed source and
wasn't built with kernel debugging support, so debugging it "from the
outside" is the only possibility and hence why debugging on accelerators
(specially HAXM/WHPX) has become absolutely necessary for my project.

 

I've noticed that `gdb_breakpoint_insert` only considers KVM so far. My
question is: Has anyone planned adding debugging support to HAXM? Or is
anyone actively working on QEMU's HAXM frontend at all? If not, I would like
to work on it myself. Are there any guidelines or things I should take into
consideration to work on this accelerator (pinging Anthony and Glauber)?
Would it be more reasonable to add debugging support to HAXM [1] directly
instead of trying to use the existing APIs from QEMU to achieve the same
thing  (I was thinking in patching memory, e.g. with `hlt` instructions, to
trigger VM exits)?

 

Just want to hear your thoughts on the matter. :-)

 

Cheers,

Alexandro Sanchez

 

[1] https://github.com/intel/haxm/

 

Re: [Qemu-devel] Debugging on HAXM

[Paolo Bonzini]

On 01/04/2018 17:35, Alexandro Sanchez Bach wrote:
> 
> I've noticed that `gdb_breakpoint_insert` only considers KVM so far. My
> question is: Has anyone planned adding debugging support to HAXM? Or is
> anyone actively working on QEMU's HAXM frontend at all? If not, I would like
> to work on it myself. Are there any guidelines or things I should take into
> consideration to work on this accelerator (pinging Anthony and Glauber)?

The main person working on HAXM is Yu Ning.  Anthony and Glauber are
only listed because they are the authors of the KVM support (and HAXM
support in turn is based on KVM).

> Would it be more reasonable to add debugging support to HAXM [1] directly
> instead of trying to use the existing APIs from QEMU to achieve the same
> thing  (I was thinking in patching memory, e.g. with `hlt` instructions, to
> trigger VM exits)?

That would probably be less "hackish", but harder too.  It would also
let you support singlestep and hardware breakpoints---they are often
better than software breakpoints for debugging if you can live with the
limit of four breakpoints.

Yu Ning, what do you think?

Paolo

Re: [Qemu-devel] Debugging on HAXM

[Yu Ning]

Sorry for the very late response.  I completely forgot to check this 
mailbox...  Adding my usual corporate email to the cc.

On 4/2/2018 10:20, Paolo Bonzini wrote:
> On 01/04/2018 17:35, Alexandro Sanchez Bach wrote:
>> I've noticed that `gdb_breakpoint_insert` only considers KVM so far. My
>> question is: Has anyone planned adding debugging support to HAXM? Or is
>> anyone actively working on QEMU's HAXM frontend at all? If not, I would like
>> to work on it myself. Are there any guidelines or things I should take into
>> consideration to work on this accelerator (pinging Anthony and Glauber)?
> The main person working on HAXM is Yu Ning.  Anthony and Glauber are
> only listed because they are the authors of the KVM support (and HAXM
> support in turn is based on KVM).

That is correct, and thanks Paolo for the introduction.  In fact I just 
reviewed a HAXM pull request from Alexandro on GitHub, so we know each 
other already.

>
>> Would it be more reasonable to add debugging support to HAXM [1] directly
>> instead of trying to use the existing APIs from QEMU to achieve the same
>> thing  (I was thinking in patching memory, e.g. with `hlt` instructions, to
>> trigger VM exits)?
> That would probably be less "hackish", but harder too.  It would also
> let you support singlestep and hardware breakpoints---they are often
> better than software breakpoints for debugging if you can live with the
> limit of four breakpoints.
>
> Yu Ning, what do you think?

First of all, I think adding debugging support to HAXM is a great idea, 
and I really look forward to Alexandro's contribution.  But I only know 
the very basics of how breakpoints work, and I'm a little confused after 
reading your discussion.

I guess the "less hackish and harder" approach Paolo referred to is the 
KVM approach, not the patching-with-HLT approach.  If so, I'd agree.  It 
seems KVM implements software breakpoints with memory patching too, 
using the INT 3 instruction, which I think requires the hypervisor to 
handle breakpoint exceptions (#BP).  Is this the sole reason to patch 
with HLT instead of INT 3, to avoid handling #BP in HAXM or perhaps 
avoid modifying the HAXM kernel module at all?

Alexandro, I'm not sure what you mean by not using existing QEMU APIs.  
Surely you still need to add HAXM-specific logic to 
gdb_breakpoint_insert(), etc., otherwise you wouldn't be able to debug 
your guest using the QEMU gdbserver?  Finally, in case you need to add 
any new HAXM APIs, please feel free to propose a design on GitHub, and 
we can continue our discussion there.  Thanks.

-Yu