Bugs item #1666308, was opened at 2007-02-22 17:09 Message generated for change (Comment added) made by jessorensen 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: Jes Sorensen (jessorensen) Date: 2010-06-03 17:21 Message: I tested this against upstream qemu and qemu-kvm git, and in both cases I was able to run the installer, so I think this issue has been resolved in upstream. I have asked iggy to close this bug, but if it reappears, please open a new bug for it in launchpad. Cheers, Jes ---------------------------------------------------------------------- Comment By: Avi Kivity (avik) Date: 2007-12-03 10:31 Message: Logged In: YES user_id=539971 Originator: NO The IDT is probably correct, but perhaps we're failing some of the checks during interupt injection (see Intel documentation for the INT instruction, for example, we may be failing "IF gate descriptor DPL < CPL then #GP(vector number * 8). I suggest adding printks() when injecting interrupts, and examining the gate descriptor and comparing it against the documentation. ---------------------------------------------------------------------- Comment By: Neo Jia (chenghuan_jia) Date: 2007-12-03 08:40 Message: Logged In: YES user_id=446034 Originator: NO So you think we make an incorrect handling for the IDT before the freedos uses a hardware task switch? Could you give me any hints/suggestions about debugging the IRQ injection? Thanks, Neo ---------------------------------------------------------------------- Comment By: Avi Kivity (avik) Date: 2007-12-02 11:18 Message: Logged In: YES user_id=539971 Originator: NO Looks like the the processor switched to protected mode and back between the last two dumps (see changes in idt, gdt). Perhaps it is trying to inject an irq and failing? Maybe idt handling is incorrect. ---------------------------------------------------------------------- Comment By: Neo Jia (chenghuan_jia) Date: 2007-12-02 09:39 Message: Logged In: YES user_id=446034 Originator: NO I think the instruction caused the problem should be the "call" instruction. But I cannot see why it causes the task switch after reading Intel manuals. The instruction should be 16 bit or 32 bit? If 32-bit, the instruction will be "call 0x0EFF3B8". But the NT bit of EFLAGS is not set... Any comments? Thanks, Neo ---------------------------------------------------------------------- Comment By: Neo Jia (chenghuan_jia) Date: 2007-12-01 10:57 Message: Logged In: YES user_id=446034 Originator: NO Avi, I put the kvm_show_regs() function after every kvm_run in qemu/qemu-kvm.c. The followings are the outputs of the last few kvm_show_regs() function. I am wondering why the last two are different. And I have decoded the RIP in the qemu. So the instruction should be rax 0000000000001192 rbx 00000000c53999a4 rcx 0000000000000000 rdx 0000000000000 403 rsi 000000007fff9eff rdi 000000009c35b000 rsp 0000000000007ba6 rbp 0000000000000 280 r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000 000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000 000 rip 000000000000e830 rflags 00023246 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 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 1000 (00010000/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 rax 0000000000001192 rbx 00000000c53999a4 rcx 0000000000000000 rdx 0000000000000 403 rip 0000000000000425 rflags 00033246 cs 0948 (00009480/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds 0b68 (0000b680/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es df00 (000df000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss 0b68 (0000b680/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs 9e24 (0009e240/0000ffff p 1 dpl 3 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 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 rax 000000000000df00 rbx 00000000564d0000 rcx 0000000000000008 rdx 0000000000000000 rsi 000000007fff00df rdi 000000009c35092c rsp 00000000000011b8 rbp 00000000000011c4 r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 rip 0000000000000425 rflags 00033246 cs 0948 (00009480/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds 0b68 (0000b680/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es df00 (000df000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss 0b68 (0000b680/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs 9e24 (0009e240/0000ffff p 1 dpl 3 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 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 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 cs:rip = 0x0948:0x0425 = 0x98a5 (qemu) xp/20hi 0x9876 0x0000000000009876: mov %al,-4(%bp) 0x0000000000009879: movb $0x0,-3(%bp) 0x000000000000987d: incb 801 0x0000000000009881: mov -4(%bp),%ax 0x0000000000009884: call 0x3c70 0x0000000000009887: mov %ax,%gs:18(%bx) 0x000000000000988b: andb $0xfe,%gs:20(%bx) 0x0000000000009890: cmpw $0x0,%gs:18(%bx) 0x0000000000009895: je 0x98a8 0x0000000000009897: orb $0x1,%gs:20(%bx) 0x000000000000989c: cmpw $0x3,12(%bp) 0x00000000000098a0: jne 0x98a8 0x00000000000098a2: mov -4(%bp),%ax 0x00000000000098a5: call 0x3b36 0x00000000000098a8: decb 801 0x00000000000098ac: jmp 0x9578 0x00000000000098af: popw -32639(%bp,%si) 0x00000000000098b3: or (%bp,%si),%cx 0x00000000000098b5: or %cx,(%bx,%si) 0x00000000000098b7: pop %es (qemu) xp/20hi 0x3b36 0x0000000000003b36: push %bx 0x0000000000003b37: push %cx 0x0000000000003b38: mov %ax,%dx 0x0000000000003b3a: les 109,%bx 0x0000000000003b3e: mov %es:4(%bx),%al 0x0000000000003b42: cbtw 0x0000000000003b43: cmp %dx,%ax 0x0000000000003b45: jne 0x3b4c 0x0000000000003b47: movb $0x0,%es:5(%bx) 0x0000000000003b4c: mov %es:(%bx),%ax 0x0000000000003b4f: mov %ax,%bx 0x0000000000003b51: mov 109,%cx 0x0000000000003b55: cmp %cx,%ax 0x0000000000003b57: jne 0x3b3e 0x0000000000003b59: pop %cx 0x0000000000003b5a: pop %bx 0x0000000000003b5b: ret 0x0000000000003b5c: push %bx 0x0000000000003b5d: push %cx 0x0000000000003b5e: push %gs So does the instruction "decb 801" cause problem? I don't trust the instructions decoded by qemu, so I print out the raw data. (qemu) xp/20hx 0x98a5 00000000000098a5: 0x8ee8 0xfea2 0x210e 0xe903 0xfcc9 0x828f 0x8081 0x0a0b 00000000000098b5: 0x0809 0x0607 0x0305 0x2a00 0x2a79 0x2a79 0xc079 0xdc74 00000000000098c5: 0xe574 0x2a74 0x2a79 0x2a79 (qemu) xp/20hx 0x98a8 00000000000098a8: 0x0efe 0x0321 0xc9e9 0x8ffc 0x8182 0x0b80 0x090a 0x0708 00000000000098b8: 0x0506 0x0003 0x792a 0x792a 0x792a 0x74c0 0x74dc 0x74e5 00000000000098c8: 0x792a 0x792a 0x792a 0x792a Any comments? ---------------------------------------------------------------------- Comment By: Neo Jia (chenghuan_jia) Date: 2007-11-26 04: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-26 01: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 10: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-25 04: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 22: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-26 00: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 18: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 18: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 18: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 20: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 09: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 10: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-03-01 03: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-03-01 01: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-03-01 00: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 10: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 19: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 19: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 17: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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
