From: Blue Swirl <blauwirbel@gmail.com>
To: Craig Brozefsky <craig@red-bean.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] software breakpoints disappearing/reappearing in KVM/qemu
Date: Fri, 8 Apr 2011 23:16:45 +0300 [thread overview]
Message-ID: <BANLkTi=sshVc3+_v_Q02iHecfPU+jvPtiQ@mail.gmail.com> (raw)
In-Reply-To: <BANLkTimB7YhJ2UPtH3c2XjAx1kvHmGWNAw@mail.gmail.com>
On Fri, Apr 8, 2011 at 9:50 PM, Craig Brozefsky <craig@red-bean.com> wrote:
> First, thank you very much for your work on KVM/QEMU and in particular
> the GDB support. I have been a heavy user of it while implementing a
> programmable debugger that monitors/traces guest operating systems. I
> need more breakpoints than hardware BPs available, and I need the
> performance of KVM acceleration.
>
> I am running into a problem with software breakpoints disappearing and
> re-appearing. I set them via the GDB stub. If I examine the location
> in the qemu monitor I will see them there, but on occasion (and with
> greater frequency the more breakpoints I have) a given breakpoint will
> disappear according to the monitor, and then re-appear.
>
> I also have processes executing the instructions at the breakpoint without
> stopping. This makes my results quite unpredictable, and it has led too a
> few days of learning all about Windows system working set paging.
>
> My first approach was to try and re-install the breakpoints after a
> page was faulted in, thinking that the INT3 was disappearing when the
> page was read back into memory. Setting a hbreak, I was trapping
> MMAccessFault, and reinstalling all by breakpoints when it hit its
> return address (after the IO Page Read Calls). That didn't solve
> the problem, and left me wondering if I need to take into consideration the way
> KVM/qemu handle guest memory. And that brings me to my question.
>
> Assuming I handle the guest kernel paging issue properly, are you
> aware of issues with the debugging support in KVM/qemu that would
> result in the INT3 blinking in and out of existence?
>
> In the meantime, I've been reading source code, but it'll be a few
> days before I figure out the details of memory mgmt under KVM. Any
> hints would be greatly appreciated.
When not using KVM but TCG, guest instructions are translated to host
instructions and these are stored to translation blocks. QEMU should
detect writes to the source pages of translation and flushes the TBs.
This is needed to support self-modifying code.
For KVM, native self-modifying code support of the CPU should be
enough. Are you sure you are using KVM, what does "info kvm" tell?
For TCG, I'd think what could happen here is that a block is
translated with (or without) INT3, but somehow the write access to
remove (or add) INT3 is undetected and the old TB is used.
How are you setting the breakpoint, with GDB interface?
next prev parent reply other threads:[~2011-04-08 20:17 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-08 18:50 [Qemu-devel] software breakpoints disappearing/reappearing in KVM/qemu Craig Brozefsky
2011-04-08 20:16 ` Blue Swirl [this message]
2011-04-08 20:37 ` Craig Brozefsky
2011-04-08 20:52 ` [Qemu-devel] " Jan Kiszka
2011-04-10 14:01 ` Avi Kivity
2011-04-10 14:23 ` Jan Kiszka
2011-04-10 14:41 ` Avi Kivity
2011-04-10 15:16 ` Jan Kiszka
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='BANLkTi=sshVc3+_v_Q02iHecfPU+jvPtiQ@mail.gmail.com' \
--to=blauwirbel@gmail.com \
--cc=craig@red-bean.com \
--cc=qemu-devel@nongnu.org \
/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).