[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] software breakpoints disappearing/reappearing in KVM/qe
Re: [Qemu-devel] software breakpoints disappearing/reappearing in KVM/qemu
Fri, 8 Apr 2011 23:16:45 +0300
On Fri, Apr 8, 2011 at 9:50 PM, Craig Brozefsky <address@hidden> 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
> 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?