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
