Re: exception on Intel with kvm-15

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

Gregory Haskins wrote:
> Hi All,
>   I was going to go back to looking at that problem I found a few weeks ago with an unexpected #UD.  However, that test machine was decommisioned so I had to build a new one.  While at it, I started with kvm-15, but now I am seeing this on startup:
>
>
> # ./qemu-system-x86_64 . -hda ~/kvm/vdisk.img -cdrom /install/SLED-10-DVD-x86_64-GMC-DVD1.iso -boot d -m 512 -L ../pc-bios/
> exception 12 (0)
> rax 000000000000031e rbx 0000000000040080 rcx 0000000000002000 rdx 0000000000011800
> rsi 00000000ffff0800 rdi 0000000000040000 rsp 0000000000087bdc rbp 0000000000000000
> r8  0000000000000000 r9  0000000000000000 r10 0000000000000000 r11 0000000000000000
> r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000
> rip 000000000000a56c rflags 00033206
> cs 0000 (00000000/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 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 (20850000/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
> Aborted
>
> I am on a Dell 490 with 2-socket/2-core Xeon 5130s (Woodcrest) on a 2.6.16.21 x86_64 based suse kernel.  I get the SDL window and it appears to blow up on the part of the bios where the drives are displayed.  If I am reading the output correctly, the RIP is at 0xa56c (presumably within Bochs) and took exception 12 (#SS).
>
> First question: does "exception 12" correlate to the Intel #SS, or did I read that wrong.
>
>   

Yes, it's a stack segment violation.

> Second question: Any ideas on whats wrong?
>
>   

The usual real mode trouble.  If you compile the bios (get bochs cvs, 
apply bios.diff, etc.) you can see the exact instruction in the 
listing.  You can also disassemble bios.bin (just top 64K, file format 
binary, arch i8086).

> Third question:  How do you guys debug problems early on in the BIOS like this?  I tried using (-S -s) and connecting GDB, but I couldn't figure out how to make it do asm debugging without providing an elf binary since the bios.bin is already stripped and setup with a custom linker.conf.   
>   

The best way is to guess what the problem is and fix it.  Failing that, 
you can try to look at the disassembly around the rip and possibly get 
inspiration from that.  Usually I end up running  qemu -no-kvm with a 
patch that prints out program counters when they are first encountered, 
then bisect to find where qemu -no-kvm and qemu -yes-kvm diverge.  The 
hardware breakpoint feature of kvm is handy for that (in fact it was 
developed for that purpose).

Oh, and sometimes I take show_code() from debug-vmx.c and stick it in 
interesting places as a faster way of seeing what the guest is doing.

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


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV