Re: gdb and kvm status?

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 3558 bytes --]

Tim Pepper wrote:
> (not on list, so please cc: replies and I'm new to kvm and qemu so
> forgive my ignorance of things)
> 
> I was trying to play recently with a kvm guest and gdb and am experiencing
> 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.
> 
> 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:
> 
>    qemu-kvm -s -S -redir tcp:2255::22 ./ubuntu8.04.1.img \
>    -kernel './vmlinux-2.6.27-rc4' -append 'console=tty0 root=/dev/hda1'
> 
> If I don't run UP for the guest I miss breakpoints, which it sounds like 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:
> 
>   qemu-system-x86_64 -s -S -redir tcp:2255::22 ./ubuntu8.04.1.img \
>   -kernel './vmlinux-2.6.27-rc4' -append 'console=tty0 root=/dev/hda1'
> 
> 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.
> 
> Output from UP is:
> unhandled vm exit: 0x80000021 vcpu_id 0
> rax 000000000003b06b rbx 0000000000000000 rcx 0000000000000008 rdx 000000000003b06b
> rsi 00000000c12e6f00 rdi 00000000c06d8f00 rsp 00000000c724fbc4 rbp 00000000c724fc04
> r8  0000000000000000 r9  0000000000000000 r10 0000000000000000 r11 0000000000000000
> r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000
> 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
> 
> 
> 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]