From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [PATCH 00/17] kvm-userspace: Fix and improve guest debugging and x86 debug registers Date: Tue, 18 Nov 2008 10:08:36 +0100 Message-ID: <49228614.3020000@siemens.com> References: <20081006091415.095241851@mchn012c.ww002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Markus Armbruster Return-path: Received: from gecko.sbs.de ([194.138.37.40]:20359 "EHLO gecko.sbs.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750857AbYKRJJh (ORCPT ); Tue, 18 Nov 2008 04:09:37 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: Markus Armbruster wrote: > Jan Kiszka writes: > > [...] >> To summarize the contributions of this series (+ its related kernel >> bits): >> - fully functional guest debugging via gdbstub, >> including hardware breakpoints and watchpoints >> (pick up current gdb cvs to have hbreak via remote gdb) >> - (Almost) unlimited number of standard breakpoints >> - SMP guest debugging support >> - x86 debug registers support (makes guest's gdb and kgdb happy) >> >> The patches are in daily use for several moons here and have proven to >> be very helpful for tricky kernel debugging task. Specifically, >> reproducing and then tracking down certain races/deadlocks on SMP boxes >> is far more comfortable with KVM than on "real metal". > > Sounds intriguing. Could you explain briefly what exactly you do to > wire a debuffer to a guest, so dummies like me can give it a whirl? It's fairly simple, at least for Linux guests: Compile and install a guest kernel with CONFIG_DEBUG_INFO, then fire up qemu with '-s'. It will tell you that it's now listening on TCP port 1234 for incoming remote gdb connections. Next you can start gdb (or some frontend like ddd) with the recently compiled 'vmlinux' and connect to qemu via 'tar[et] re[mote] :1234'. You are now able to do source-level debugging with you guest kernel. Some things you may want to play with: o Switching between the guest VCPUs (use 'info threads' and 'thread ') o Hardware breakpoints ('hbreak '), useful if you don't want kvm to insert INT3 in the guest code or if the target address is currently not addressable o Hardware watchpoints ('watch ') BTW, the recommended gdb version for full functionality is not yet released AFAIK: it's post 6.8. Release 6.8 introduced hbreak/watch via remote links and fixed thread selection for single-stepping, but had problems here with reading vmlinux symbols. Yesterday I posted a new version of the qemu bits in this series and I'm now hoping for their inclusion. A rebase of the kvm part will soon be set out as well, but if you stumble over problems with what is currently available for kvm earlier, let me know, will then try to accelerate things. Enjoy, Jan -- Siemens AG, Corporate Technology, CT SE 2 ES-OS Corporate Competence Center Embedded Linux