From: Paolo Bonzini <pbonzini@redhat.com>
To: Alexandro Sanchez Bach <alexaltea123@gmail.com>, qemu-devel@nongnu.org
Cc: 'Anthony Liguori' <aliguori@us.ibm.com>,
'Glauber Costa' <gcosta@redhat.com>,
Yu Ning <yu.ning@linux.intel.com>
Subject: Re: [Qemu-devel] Debugging on HAXM
Date: Mon, 2 Apr 2018 04:20:24 +0200 [thread overview]
Message-ID: <29f1952e-325f-0a60-041c-fc651ae33fbb@redhat.com> (raw)
In-Reply-To: <000001d3c9cf$19f0a190$4dd1e4b0$@gmail.com>
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
next prev parent reply other threads:[~2018-04-02 2:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-01 15:35 [Qemu-devel] Debugging on HAXM Alexandro Sanchez Bach
2018-04-02 2:20 ` Paolo Bonzini [this message]
2018-04-12 9:09 ` Yu Ning
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=29f1952e-325f-0a60-041c-fc651ae33fbb@redhat.com \
--to=pbonzini@redhat.com \
--cc=alexaltea123@gmail.com \
--cc=aliguori@us.ibm.com \
--cc=gcosta@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yu.ning@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).