On Tuesday 08 January 2008 03:35:48 Dave Hansen wrote: > With kvm-44, I thought my kernel was freezing during boot if I gave it > 1G of RAM. But, it boots fine with 512M. > > So, I instrumented the kernel, and found out that it is just taking a > long time to memset a 58MB area of memory for mem_map[]. It appears to > be taking a mmio_exit for every access of every byte of memory. The end > result is a ~100kbps memset() speed. Yes, 100 kilobytes/sec. > > I just tried kvm from git, and the kernel doesn't even get that far. I > see this in debugfs > > insn_emulation:1393985 > > even before I get a single kernel message. And it keeps going up, fast. > I can get the kernel to boot just fine if I give it less than 896MB of > RAM. > > kvm-44 boots long enough for me to see a really funky e820 table: > > BIOS-provided physical RAM map: > BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) > BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) > BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved) > BIOS-e820: 0000000000100000 - 00000000fffbd000 (usable) > BIOS-e820: 00000000fffbd000 - 00000000ffff0000 (reserved) > > Note that this is with '-m 1G'!! It looks to me like one of those
And there lies the problem. qemu doesn't understand suffixes like 'G'. If you pass -m 1024, you'll boot just fine. This is really annoying of qemu (it should either accept that input properly or bail out); a patch is welcome! > sections is basically from 0x100000 up to ~4G and *usable*. That > doesn't look right. > > Eventually, the kvm-git one just pukes: > > exception 13 (33) > rax 0000000000000002 rbx 0000000000002000 rcx 0000000000000000 rdx > 0000000000000000 rsi 00000000002a1358 rdi 0000000000099100 rsp > 000000000000673a rbp 000000000000673a r8 0000000000000000 r9 > 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 > 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 > 0000000000000000 rip 000000000000fb24 rflags 00033086 > cs 9020 (00090200/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ds 9000 (00090000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > es 9000 (00090000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > ss 9000 (00090000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > fs 9000 (00090000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) > gs 9000 (00090000/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 8f5c/27 > idt 0/3ff > cr0 60000010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 > code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --> f0 01 > f0 03 0e 00 00 00 70 01 70 03 0f 00 00 00 e8 01 e0 03 0c 00 00 00 68 01 60 > 03 0b 00 Aborted > > Any idea how to debug this? > > -- Dave ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
