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