From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39375 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q8GlV-0001FR-H0 for qemu-devel@nongnu.org; Fri, 08 Apr 2011 14:50:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q8GlS-00077q-Ad for qemu-devel@nongnu.org; Fri, 08 Apr 2011 14:50:41 -0400 Received: from mail-bw0-f45.google.com ([209.85.214.45]:38167) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q8GlR-00076r-LD for qemu-devel@nongnu.org; Fri, 08 Apr 2011 14:50:37 -0400 Received: by bwz16 with SMTP id 16so3420431bwz.4 for ; Fri, 08 Apr 2011 11:50:35 -0700 (PDT) MIME-Version: 1.0 Sender: craigbrozefsky@gmail.com Date: Fri, 8 Apr 2011 13:50:35 -0500 Message-ID: From: Craig Brozefsky Content-Type: text/plain; charset=ISO-8859-1 Subject: [Qemu-devel] software breakpoints disappearing/reappearing in KVM/qemu List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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.