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. Thank you for your time.