On Fri, Sep 5, 2008 at 11:28 PM, Tim Pepper <[EMAIL PROTECTED]> 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 > 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 ? > -- > Tim Pepper <[EMAIL PROTECTED]> > IBM Linux Technology Center > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > I am not currently running fedora so I'd like to know what version of kvm (kernel modules and userspace) are you running?
Anyways, the vmexit is caused because the guest is in an invalid state and fails VMX entry checks. I'll look further into the output to see where exactly the guest fails. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
