From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40984 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q8I79-0006XQ-6T for qemu-devel@nongnu.org; Fri, 08 Apr 2011 16:17:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q8I77-0007cP-Oe for qemu-devel@nongnu.org; Fri, 08 Apr 2011 16:17:07 -0400 Received: from mail-vx0-f173.google.com ([209.85.220.173]:57184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q8I77-0007cL-MN for qemu-devel@nongnu.org; Fri, 08 Apr 2011 16:17:05 -0400 Received: by vxb41 with SMTP id 41so3403197vxb.4 for ; Fri, 08 Apr 2011 13:17:05 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Fri, 8 Apr 2011 23:16:45 +0300 Message-ID: Subject: Re: [Qemu-devel] software breakpoints disappearing/reappearing in KVM/qemu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Craig Brozefsky Cc: qemu-devel@nongnu.org On Fri, Apr 8, 2011 at 9:50 PM, Craig Brozefsky wrote: > First, thank you very much for your work on KVM/QEMU and in particular > the GDB support. =C2=A0I have been a heavy user of it while implementing = a > programmable debugger that monitors/traces guest operating systems. =C2= =A0I > 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. =C2=A0I set them via the GDB stub. =C2=A0If I examine the l= ocation > 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 withou= t > stopping. =C2=A0This 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. =C2=A0Setting a hbreak, I was trapping > MMAccessFault, and reinstalling all by breakpoints when it hit its > return address (after the IO Page Read Calls). =C2=A0That didn't solve > the problem, and left me wondering if I need to take into consideration t= he way > KVM/qemu handle guest memory. =C2=A0And 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. =C2=A0Any > 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?