Re: [ kvm-Bugs-1666308 ] Freedos HIMEM.EXE hangs kvm-14 qemu on Intel CPU

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Neo Jia wrote:
> Avi,
>
> May I have your comments on the output I got from KVM CS:RIP instructions?
>
>   

The xor instruction can't cause a task switch.  Suggest adding printk()s 
to the kernel to see what is happening.

> Thanks,
> Neo
>
> On Nov 25, 2007 7:05 PM, SourceForge.net <noreply-pyega4qmqnRoyOMFzWx49A@public.gmane.org> 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
>>
>>     
>
>
>
>   


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
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