From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: gdb and kvm status? Date: Mon, 08 Sep 2008 08:48:28 +0200 Message-ID: <48C4CABC.1080201@web.de> References: <20080905202800.GA2768@tpepper-t61p.dolavim.us> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF4621769D16E4A0987CFDD72" Cc: kvm@vger.kernel.org To: Tim Pepper Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:43704 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751876AbYIHGsd (ORCPT ); Mon, 8 Sep 2008 02:48:33 -0400 In-Reply-To: <20080905202800.GA2768@tpepper-t61p.dolavim.us> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF4621769D16E4A0987CFDD72 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tim Pepper wrote: > (not on list, so please cc: replies and I'm new to kvm and qemu so > forgive my ignorance of things) >=20 > I was trying to play recently with a kvm guest and gdb and am experienc= ing > bad behavior. I'm curious if this is expected to work currently or if > there's newer code upstream that's better? I see a couple mailing list= > posts around this topic in the last months, but didn't yet go pouring > through code to see how much of the stuff kicked around actually went > into an upstream and at what versions. >=20 > For background, I've got an Ubuntu 8.04.1 guest image, a Fedora 9 host,= and the guest > is being booted directly to a 2.6.26-rc4 kernel, eg: >=20 > qemu-kvm -s -S -redir tcp:2255::22 ./ubuntu8.04.1.img \ > -kernel './vmlinux-2.6.27-rc4' -append 'console=3Dtty0 root=3D/dev/h= da1' >=20 > If I don't run UP for the guest I miss breakpoints, which it sounds lik= e is SMP debugging with both vanilla qemu and kvm is broken, you need additional patches to get a usable environment. > expected. But worse, I'm getting crashes with kvm. Things are fine > (albeit slower) if run without kvm, eg: >=20 > qemu-system-x86_64 -s -S -redir tcp:2255::22 ./ubuntu8.04.1.img \ > -kernel './vmlinux-2.6.27-rc4' -append 'console=3Dtty0 root=3D/dev/hd= a1' >=20 > The host specifics are standard current fedora/livna: > kernel-2.6.25.14-108.fc9.i686 > qemu-0.9.1-6.fc9.i386 > kmod-kqemu-1.3.0-0.38.lvn9.i686 > kmod-kqemu-2.6.25.14-108.fc9.i686-1.3.0-0.38.lvn9.i686 > kqemu-1.3.0-0.7.pre11.lvn9.noarch > And the host hardware is Intel core duo. >=20 > Output from UP is: > unhandled vm exit: 0x80000021 vcpu_id 0 > rax 000000000003b06b rbx 0000000000000000 rcx 0000000000000008 rdx 0000= 00000003b06b > rsi 00000000c12e6f00 rdi 00000000c06d8f00 rsp 00000000c724fbc4 rbp 0000= 0000c724fc04 > r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000= 000000000000 > r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000= 000000000000 > rip 00000000c01c1a6b rflags 00000246 > cs 0060 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0) > ds 007b (00000000/ffffffff p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) > es 007b (00000000/ffffffff p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 0) > ss 0068 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) > fs 00d8 (00c0e000/ffffffff p 1 dpl 0 db 0 s 1 type 3 l 0 g 1 avl 0) > gs 0033 (b7d926b0/ffffffff p 1 dpl 3 db 1 s 1 type 3 l 0 g 1 avl 1) > tr 0080 (c12e7400/0000206b p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) > ldt 0000 (00000000/ffffffff p 0 dpl 0 db 0 s 0 type 0 l 0 g 0 avl 0) > gdt c11c4000/ff > idt c055c000/7ff > cr0 8005003b cr2 80bc960 cr3 5c2a000 cr4 690 cr8 0 efer 0 > Aborted >=20 >=20 > So...Normal/expected behavior or ? That the existing code is able to oops was new to me, but I never seriously tried what comes by default (due to all the missing features and known limitations). However, I just rebased my full gdb series for qemu on top of kvm and also refreshed the kvm guest debugging patches once again. I will try to find some time sending them out soon, at least for early adopters. The first part is still awaiting the honour to be reviewed and finally merged by qemu people. And as long as this didn't happen, the kvm part will not be accepted here as well. Unfortunately, the last feedback I received from qemu maintainers involved in the touched components was that there are "more interesting features" to be addressed first. Well, depends on your POV... Jan --------------enigF4621769D16E4A0987CFDD72 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjEyr0ACgkQniDOoMHTA+l1kgCeLa2eiVjl0FWw7nImpGWiNgip jNsAmwa7PkhjRmsq0mBqEf5cFlNfz428 =qHlW -----END PGP SIGNATURE----- --------------enigF4621769D16E4A0987CFDD72--