Avi, May I have your comments on the output I got from KVM CS:RIP instructions?
Thanks, Neo On Nov 25, 2007 7:05 PM, SourceForge.net <[EMAIL PROTECTED]> wrote: > Bugs item #1666308, was opened at 2007-02-22 08:09 > Message generated for change (Comment added) made by chenghuan_jia > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1666308&group_id=180599 > > Please note that this message will contain a full copy of the comment thread, > including the initial issue submission, for this request, > not just the latest update. > Category: None > Group: None > Status: Open > Resolution: Later > Priority: 5 > Private: No > Submitted By: David A. Madore (davidamadore) > Assigned to: Izik Eidus (izike) > Summary: Freedos HIMEM.EXE hangs kvm-14 qemu on Intel CPU > > Initial Comment: > Host system summary: Intel CPU (Pentium D 3.40GHz) running Linux 2.6.20.1 in > 64-bit (x86_64) mode, using KVM module and QEMU from kvm-14 release. > Otherwise generally using the Debian Etch distribution. > > Try to launch Freedos installation using "-hda harddrive.img -cdrom > fdbasecd.iso -boot d -m 64 -localtime", where fdbasecd.iso is Freedos 1.0's > base install CD from <URL: http://www.freedos.org/freedos/files/ > (and > harddrive.img is an 80MB file full of zeros, but this is unimportant). Using > bochsbios-2.3-2 and vgabios-0.6a-1 (both packaged by Debian). > > Symptom: virtual machine boots, but qemu stops soon after entering Freedos > installer (as soon as "install to hard drive" is chosen, or something). > > "Stopped" means that the window title bar is updated to add "[stopped]" after > QEMU title, and the virtual machine no longer runs (on host system, the QEMU > process is in T state, using 0% CPU). The QEMU monitor is still accessible, > but "cont" has no effect. "info registers" does not seem to show anything > strange. > > The same QEMU running with -no-kvm works fine, so it's more likely a KVM or > KVM-QEMU interface issue, not with QEMU. The same QEMU+KVM boots a Knoppix > 5.0 CD without problem, so it's not like a complete failure to run anything. > Using kvm-12 instead of kvm-14 gives a QEMU segfault at the same point > (rather than just going in "stopped" mode). > > Reported on freenode's #irc channel on 2007-02-22 15:40+0100. Someone > confirmed having the same problem on a 32-bit kernel+userland with FC6 (so > it's not x86_64-specific, nor Debian-specific), but also with an Intel CPU. > > ---------------------------------------------------------------------- > > Comment By: Neo Jia (chenghuan_jia) > Date: 2007-11-25 19:05 > > Message: > Logged In: YES > user_id=446034 > Originator: NO > > Avi, > > I think for No.3 case is the one I need to implement first. But how to > check the value of CS:RIP? > > CS:RIP = 0x0684:03fd = 0x6c3d > > I run the same command as previous comments in this bug report: > > (qemu) xp/10ih 0x6c3d > 0x0000000000006c3d: xor (%bx,%si),%ax > 0x0000000000006c3f: jl 0x6c5d > 0x0000000000006c41: pushw 816 > 0x0000000000006c45: pushw %gs:51(%si) > 0x0000000000006c49: pushl %gs:21(%si) > 0x0000000000006c4e: push $0x0 > 0x0000000000006c50: push %di > 0x0000000000006c51: push $0x1 > 0x0000000000006c53: call 0x2b72 > 0x0000000000006c56: test %ax,%ax > > Is that correct? > > Thanks, > Neo > > > ---------------------------------------------------------------------- > > Comment By: Neo Jia (chenghuan_jia) > Date: 2007-11-25 16:36 > > Message: > Logged In: YES > user_id=446034 > Originator: NO > > Avi, > > Thanks. I have tried to reproduce this problem on my Intel E6600 (x86_64 > 2.6.23.1-49.fc8) with the latest kvm module and userspace. > > I found several crashes/hungs in the installation. Not sure if we need to > file different bug to track them. > > I used a 128M qcow image and with the following line to install freeDOS: > "sudo qemu-system-x86_64 -cdrom /home/cjia/download/fdbasecd.iso -hda > freedos.img -boot d -m 1024" > > 1. Crashes when I happened to boot the empty image at the very beginning > of the installation by selecting "h". > > exception 12 (0) > rax 0000000000000037 rbx 00000000c5390000 rcx 0000000000000000 rdx > 0000000000000080 > rsi 000000007fff37b8 rdi 000000009c35b404 rsp 000000000000ffff rbp > 0000000000000280 > r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 > 0000000000000000 > r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 > 0000000000000000 > rip 000000000000840f rflags 00033046 > cs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ds 2000 (00020000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > es 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ss 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > fs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > gs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > tr 0000 (fffbd000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) > ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) > gdt fa9d0/30 > idt 0/3ff > cr0 60000010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 > Segmentation fault > > dmesg: qemu-system-x86[3365]: segfault at 00002aaaaadfe3fb rip > 00000000004f4045 rsp 00007fff1c020f40 error 4 > > 2. Keyboard error, this happens in the running of extended fdisk. When it > is formatting the hard disk, I clicked my mouse in the FreeDOS screen. It > stucked. > > dmesg: kvm_handle_exit: unexpected, valid vectoring info and exit reason > is 0x1e > > 3. unhandled vm exit: 0x9 vcpu_id 0, this happens when I am trying to boot > the installed freeDOS with Load FreeDOS with EMM386+EMS and SHARE. > > unhandled vm exit: 0x9 vcpu_id 0 > rax 0000000000000340 rbx 00000000000008ec rcx 0000000000000000 rdx > 00000000000007ac > rsi 0000000000126340 rdi 0000000000273000 rsp 00000000000011f0 rbp > 0000000000003be0 > r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 > 0000000000000000 > r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 > 0000000000000000 > rip 00000000000003fd rflags 00000002 > cs 0684 (00006850/0000ffff p 1 dpl 0 db 0 s 1 type b l 0 g 0 avl 0) > ds 0030 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) > es 0030 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) > ss 0000 (0000b680/0000ffff p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0) > fs 0014 (00003be0/00002c66 p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0) > gs 032f (000032f0/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > tr 0018 (00004704/00000068 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) > ldt 0008 (00003ee4/00000020 p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) > gdt 3e64/7f > idt 124784/7ff > cr0 60000011 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 > Aborted > > Any comments? > > Thanks, > Neo > > > ---------------------------------------------------------------------- > > Comment By: Avi Kivity (avik) > Date: 2007-11-25 01:59 > > Message: > Logged In: YES > user_id=539971 > Originator: NO > > Start by verifying that it occurs, and checking which instruction does not > work. You can do that by printing the code in cs:rip when handle_exit() > encounters exit reason 9. > > Once the instruction is known we need to emulate it according to the > manual. > > ---------------------------------------------------------------------- > > Comment By: Neo Jia (chenghuan_jia) > Date: 2007-11-24 19:11 > > Message: > Logged In: YES > user_id=446034 > Originator: NO > > Avi, > > Could you provide some hints or estimation about this work? And, where > should I start or look first? > > (I think we need to have it since it is on the TODO list.) > > Thanks, > Neo > > ---------------------------------------------------------------------- > > Comment By: Avi Kivity (avik) > Date: 2007-09-05 13:08 > > Message: > Logged In: YES > user_id=539971 > Originator: NO > > This is hardware task switch support which isn't used by modern operating > systems. It is possible to emulate in software, but a lot of work to do. > > ---------------------------------------------------------------------- > > Comment By: David A. Madore (davidamadore) > Date: 2007-08-25 15:06 > > Message: > Logged In: YES > user_id=2506 > Originator: YES > > By the way, perhaps this is a stupid question[#] or perhaps I don't > understand what this is all about, but if kvm doesn't have task switch > support, isn't it possible to do that part in software like the no-kvm qemu > does? Isn't it possible to copy that bit of code from the no-kvm qemu and > do this "task switch" thingy in software? > > [#] I guess I don't understand what "task switch support" means, because > in my understanding of the term, Linux does task switching and Linux ran > fine under qemu+kvm last time I tried. So I guess you are referring to > some very specific kind of task switching. > > ---------------------------------------------------------------------- > > Comment By: Avi Kivity (avik) > Date: 2007-07-31 09:54 > > Message: > Logged In: YES > user_id=539971 > Originator: NO > > Oh no! doesn't work == open bug. > > ---------------------------------------------------------------------- > > Comment By: David A. Madore (davidamadore) > Date: 2007-07-31 09:49 > > Message: > Logged In: YES > user_id=2506 > Originator: YES > > Thanks for the explanation! I guess that closes this bug then. > > ---------------------------------------------------------------------- > > Comment By: Izik Eidus (izike) > Date: 2007-07-31 09:42 > > Message: > Logged In: YES > user_id=1851802 > Originator: NO > > the problem that you are experience come from the fact that kvm currently > dont have implemented task switch support. (freedos use task switch ) > there is an hope to bring task switch support into kvm, but i will take > some time. > > thanks. > > ---------------------------------------------------------------------- > > Comment By: David A. Madore (davidamadore) > Date: 2007-07-28 11:59 > > Message: > Logged In: YES > user_id=2506 > Originator: YES > > The problem has evolved, but it is not fixed: now FreeDOS installation > works, but if you try to boot a freshly installed system using the menu > entry that says "Load FreeDOS with EMM386+EMS and SHARE", kvm aborts with > the following error dump: > > vega david /opt/kvm-33/bin $ qemu-system-x86_64 -hda /tmp/harddrive.img > -cdrom /data/FTP/freedos-1.0-basecd.iso -m 64 -localtime -boot c > unhandled vm exit: 0x9 > rax 0000000000000340 rbx 0000000000000504 rcx 0000000000000000 rdx > 00000000000007ac > rsi 0000000000126340 rdi 0000000000161000 rsp 00000000000011f0 rbp > 0000000000003a60 > r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 > 0000000000000000 > r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 > 0000000000000000 > rip 00000000000003fd rflags 00000002 > cs 066c (000066d0/0000ffff p 1 dpl 0 db 0 s 1 type b l 0 g 0 avl 0) > ds 0030 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) > es 0030 (00000000/ffffffff p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) > ss 0000 (0000b500/0000ffff p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0) > fs 0014 (00003a60/00002c66 p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0) > gs 0317 (00003170/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > tr 0018 (00004584/00000068 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) > ldt 0008 (00003d64/00000020 p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) > gdt 3ce4/7f > idt 124784/7ff > cr0 60000011 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 > zsh: abort qemu-system-x86_64 -hda /tmp/harddrive.img -cdrom -m 64 > -localtime -boot c > > > ---------------------------------------------------------------------- > > Comment By: Izik Eidus (izike) > Date: 2007-07-25 00:43 > > Message: > Logged In: YES > user_id=1851802 > Originator: NO > > this bug is fixed in newer kvm versions. > i tested it with kvm-32 and it didnt hang. > > ---------------------------------------------------------------------- > > Comment By: Avi Kivity (avik) > Date: 2007-03-05 01:03 > > Message: > Logged In: YES > user_id=539971 > Originator: NO > > Okay. Can you update the guest status page > (http://kvm.qumranet.com/kvmwiki/Guest_Support_Status) with your results > and workaround? > > I'll try to take a detailed look at it when I get some time, unfortunately > this won't be very soon. > > ---------------------------------------------------------------------- > > Comment By: chris (melander1) > Date: 2007-02-28 18:04 > > Message: > Logged In: YES > user_id=1158530 > Originator: NO > > This appears to result from FreeDOS's HIMEM.EXE extended memory (XMS) > driver. I was able to install FreeDOS by disabling KVM and using QEMU. I > then stepped through the initialization scripts. KVM went "Stopped" at the > HIMEM.EXE step. > > Regards, > > ---------------------------------------------------------------------- > > Comment By: David A. Madore (davidamadore) > Date: 2007-02-28 16:02 > > Message: > Logged In: YES > user_id=2506 > Originator: YES > > Sorry, ignore previous comment (I was using "-boot cdrom" rather than > "-boot d", and apparently it was trying to boot from the (non-bootable, and > empty) hard drive, which caused an abort... probably not a good thing, but > not the problem we're worried about). > > I added the kvm_show_regs() as you suggested, and here are the last two > register dumps before emulation stops: > > rax 0000000060000011 rbx 0000000000000784 rcx 0000000000000100 rdx > 0000000000000000 > rsi 0000000003fc0360 rdi 000000000008e898 rsp 0000000000000780 rbp > 0000000000000796 > r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 > 0000000000000000 > r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 > 0000000000000000 > rip 0000000000003d0a rflags 00010006 > cs f000 (000f0000/0000ffff p 1 dpl 0 db 0 s 1 type b l 0 g 0 avl 0) > ds 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0) > es 0028 (0009f400/0000ffff p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0) > ss 0000 (0009f400/0000ffff p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0) > fs 8cd8 (0008cd80/0000ffff p 1 dpl 0 db 0 s 1 type 3 l 0 g 0 avl 0) > gs 00d1 (00000d10/0000ffff p 1 dpl 1 db 0 s 1 type 3 l 0 g 0 avl 0) > tr 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) > ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) > gdt 9f760/2f > idt f0000/0 > cr0 60000011 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 > rax 0000000000020702 rbx 000000000000fd24 rcx 0000000000000000 rdx > 0000000000000c09 > rsi 0000000000030000 rdi 000000000000214e rsp 0000000000002112 rbp > 0000000000002142 > r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 > 0000000000000000 > r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 > 0000000000000000 > rip 0000000000000911 rflags 00023702 > cs 0262 (00002620/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ds 0262 (00002620/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > es 9d22 (0009d220/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ss 9d22 (0009d220/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > fs 00d1 (00000d10/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > gs 0262 (00002620/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > tr 0000 (04850000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) > ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) > gdt 9f760/2f > idt 0/3ff > cr0 60000010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 > > Oddly enough, the qemu monitor doesn't have the same opinion on what the > registers are: after emulation stops, > > (qemu) info registers > EAX=00000623 EBX=00000800 ECX=00000001 EDX=078bfbfd > ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 > EIP=0000fff0 EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 > ES =0000 00000000 0000ffff 00000000 > CS =f000 ffff0000 0000ffff 00000000 > SS =0000 00000000 0000ffff 00000000 > DS =0000 00000000 0000ffff 00000000 > FS =0000 00000000 0000ffff 00000000 > GS =0000 00000000 0000ffff 00000000 > LDT=0000 00000000 0000ffff 00008000 > TR =0000 00000000 0000ffff 00008000 > GDT= 00000000 0000ffff > IDT= 00000000 0000ffff > CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 > FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80 > FPR0=0000000000000000 0000 FPR1=0000000000000000 0000 > FPR2=0000000000000000 0000 FPR3=0000000000000000 0000 > FPR4=0000000000000000 0000 FPR5=0000000000000000 0000 > FPR6=0000000000000000 0000 FPR7=0000000000000000 0000 > XMM00=00000000000000000000000000000000 > XMM01=00000000000000000000000000000000 > XMM02=00000000000000000000000000000000 > XMM03=00000000000000000000000000000000 > XMM04=00000000000000000000000000000000 > XMM05=00000000000000000000000000000000 > XMM06=00000000000000000000000000000000 > XMM07=00000000000000000000000000000000 > > Ah, come to think of it, that CS:EIP means the processor shut down, > doesn't it? Is there some way to tell what caused the shutdown? > > Here's a dump of instructions around CS:IP=0262:0911=00002F31 (pretty > unremarkable, I'd think), > > (qemu) xp/30ih 0x2f20 > 0x0000000000002f20: push %ax > 0x0000000000002f21: popf > 0x0000000000002f22: pushf > 0x0000000000002f23: pop %ax > 0x0000000000002f24: and $0xf,%ah > 0x0000000000002f27: cmp $0xf,%ah > 0x0000000000002f2a: je 0x2f3a > 0x0000000000002f2c: mov $0x7,%ah > 0x0000000000002f2e: push %ax > 0x0000000000002f2f: popf > 0x0000000000002f30: pushf > 0x0000000000002f31: pop %ax > 0x0000000000002f32: and $0x7,%ah > 0x0000000000002f35: je 0x2f3a > 0x0000000000002f37: popf > 0x0000000000002f38: clc > 0x0000000000002f39: ret > 0x0000000000002f3a: popf > 0x0000000000002f3b: stc > 0x0000000000002f3c: ret > 0x0000000000002f3d: inc %bx > 0x0000000000002f3e: popa > 0x0000000000002f3f: outsb %ds:(%si),(%dx) > 0x0000000000002f40: daa > 0x0000000000002f41: je 0x2f63 > 0x0000000000002f43: imul $0x6c62,%fs:97(%bp,%di),%si > 0x0000000000002f49: and %al,%gs:50(%bx,%di) > 0x0000000000002f4d: xor %ah,(%bx,%si) > 0x0000000000002f4f: sub $0x6920,%ax > 0x0000000000002f52: addr32 outsb %ds:(%esi),(%dx) > > and here's a stack dump at the same point (SS:SP=9D22:2122=0009F332): > > (qemu) xp/80xw 0x9f330 > 000000000009f330: 0x37029d22 0x0d963a83 0x0000214e 0x00030000 > 000000000009f340: 0x00000262 0x0000106f 0x0000214e 0x0002005e > 000000000009f350: 0x10533246 0x00089d22 0x13620061 0x9d228fad > 000000000009f360: 0x21780000 0x005ea8ea 0x214e0262 0x001e9d22 > 000000000009f370: 0x04000000 0x3006000d 0x040000fd 0x7cbdfff0 > 000000000009f380: 0x9d22105c 0x02034b02 0x00d10000 0x454d4948 > 000000000009f390: 0x0000004d 0x0262105c 0x000021a0 0x00000f66 > 000000000009f3a0: 0x0000b7cb 0x0262219c 0x02360262 0x32068fad > 000000000009f3b0: 0x02033f5f 0x00d10000 0x00050001 0x7cbdfff0 > 000000000009f3c0: 0x000021b8 0x0f660247 0xb73c0247 0x00010000 > 000000000009f3d0: 0x0002b041 0x00050000 0xfffe21ca 0x0000fffe > 000000000009f3e0: 0xa5550000 0xa3510000 0x20640000 0xf306e6d9 > 000000000009f3f0: 0x551616c2 0x01a9b052 0x00000000 0x00000000 > 000000000009f400: 0x027c0008 0x03dc0394 0x2689662e 0xa32e03d4 > 000000000009f410: 0xd08c03da 0x03d8a32e 0xd08ec88c 0xc0268b2e > 000000000009f420: 0x2e525203 0x03bc1632 0x740b785a 0x163a2e4d > 000000000009f430: 0x027203bc 0xa12ecafe 0x2e9c03da 0x03a01eff > 000000000009f440: 0xe589559c 0xdb3e802e 0x11740803 0xdb3e802e > 000000000009f450: 0x06751503 0x800446f6 0x568a0375 0x53665004 > 000000000009f460: 0x02468b1e 0x1ec5662e 0x478803d4 0x5b661f04 > > ...Anyway, I don't know what to make of all that. > > ---------------------------------------------------------------------- > > Comment By: David A. Madore (davidamadore) > Date: 2007-02-28 15:28 > > Message: > Logged In: YES > user_id=2506 > Originator: YES > > I tried doing adding the kvm_show_regs() as you suggested, but now qemu > aborts long before it even gets to the point where it stopped previously. > Here are the last two register dumps before it aborts: > > rax 0000000000000100 rbx 0000000000000190 rcx 000000008000001a rdx > 0000000000000177 > rsi 00000000ffff009d rdi 000000000004f7f4 rsp 000000000008fdcd rbp > 000000000000fdcf > r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 > 0000000000000000 > r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 > 0000000000000000 > rip 00000000000004e6 rflags 00023206 > cs f000 (000f0000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ds 9fc0 (0009fc00/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > es 0080 (00000800/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ss 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > fs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > gs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > tr 0000 (04850000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) > ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) > gdt fa4d1/37 > idt 0/3ff > cr0 60000010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 > exception 13 (0) > rax 000000000000f001 rbx 000000000000d6b7 rcx 0000000080000001 rdx > 0000000000000000 > rsi 00000000ffff009d rdi 000000000004f7f4 rsp 000000000008ffb8 rbp > 000000000000ffcc > r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 > 0000000000000000 > r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 > 0000000000000000 > rip 0000000000000a45 rflags 00033002 > cs f000 (000f0000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ds 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > es 07c0 (00007c00/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ss 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > fs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > gs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > tr 0000 (04850000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) > ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) > gdt fa4d1/37 > idt 0/3ff > cr0 60000010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 > zsh: abort /opt/kvm-14-debug/bin/qemu-system-x86_64 -hda > /tmp/empty.img -cdrom -m 64 > > But if you're interested in a register dump, I can probably provide one > from the qemu monitor... I'll see what I can do. > > ---------------------------------------------------------------------- > > Comment By: Avi Kivity (avik) > Date: 2007-02-28 01:06 > > Message: > Logged In: YES > user_id=539971 > Originator: NO > > one way to debug is to add a kvm_show_regs() (user/kvmctl.h) after every > kvm_run() (qemu/qemu-kvm.c). it will slow down the guest tremendously, and > produce copious output, but it can help show what the guest is doing by > correlating rip to freedos symbold. > > ---------------------------------------------------------------------- > > Comment By: David A. Madore (davidamadore) > Date: 2007-02-22 10:43 > > Message: > Logged In: YES > user_id=2506 > Originator: YES > > Just in case that's of any use, here's a strace of qemu encountering the > problem: <URL: http://www.madore.org/~david/.tmp/qemu-kvm-14-strace.out.bz2 > > (beware, it's 540kB compressed but it expands to 57MB). I'm also willing > to run under gdb if given some explanations on how to do that. > > ---------------------------------------------------------------------- > > Comment By: David A. Madore (davidamadore) > Date: 2007-02-22 10:30 > > Message: > Logged In: YES > user_id=2506 > Originator: YES > > Sorry, my bad: I *am* using the BIOS images provided with kvm-14: > > 6202 open("/opt/kvm-14/share/qemu/bios.bin", O_RDONLY) = 9 > 6202 open("/opt/kvm-14/share/qemu/bios.bin", O_RDONLY) = 9 > 6202 open("/opt/kvm-14/share/qemu/vgabios-cirrus.bin", O_RDONLY) = 9 > > Another bit of info I might add: when QEMU starts, the message > > kvm: msrs: 6 > > appears in dmesg (this is *before* QEMU hangs, so it's probably > irrelevant, but just in case...). > > If there's any more info I can provide, please let me know. > > ---------------------------------------------------------------------- > > Comment By: Avi Kivity (avik) > Date: 2007-02-22 08:25 > > Message: > Logged In: YES > user_id=539971 > Originator: NO > > Please try using the bios images provided with kvm-14. Supporting the > bios on Intel hardware is tricky. > > ---------------------------------------------------------------------- > > You can respond by visiting: > https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1666308&group_id=180599 > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using! ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
