Slow Kernel Boot

Slow Kernel Boot

[Dave Hansen]

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

Re: Slow Kernel Boot

[Izik Eidus]

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
> sections is basically from 0x100000 up to ~4G and *usable*.  That
> doesn't look right.
>   
yea it really dont look right, it look like it for some reason map the 
whole memory up untill the bios to the kernel as memory
it even map it on the pci hole so...
hrmmm, very weird,

what is your host info (32/64 amd/intel kernel...)? and what is the 
guest info (kernel 32/64...) ?
and what happen if you run it with -no-kvm ?
and are you using new kvm-userspace as well? or just new kvm kernel 
modules (or is is the oppiste?)


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

Re: Slow Kernel Boot

[Dave Hansen]

On Tue, 2008-01-08 at 00:16 +0200, Izik Eidus wrote:
> 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
> > sections is basically from 0x100000 up to ~4G and *usable*.  That
> > doesn't look right.
> >   
> yea it really dont look right, it look like it for some reason map the 
> whole memory up untill the bios to the kernel as memory
> it even map it on the pci hole so...
> hrmmm, very weird,
> 
> what is your host info (32/64 amd/intel kernel...)?

64-bit intel host, kernel 2.6.24-rc5

Running kvm's current git userspace with modules from the same version.

> and what is the 
> guest info (kernel 32/64...) ?

32-bit 2.6.23-rc6-mm1

> and what happen if you run it with -no-kvm ?

Both current -git and kvm-44 seem to lock up at early kernel boot before
even early printk is available.  But, GRUB comes up in both cases. 

-no-kvm doesn't seem to change things at all.

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

Re: Slow Kernel Boot

[Izik Eidus]

Dave Hansen wrote:
> On Tue, 2008-01-08 at 00:16 +0200, Izik Eidus wrote:
>   
>> 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
>>> sections is basically from 0x100000 up to ~4G and *usable*.  That
>>> doesn't look right.
>>>   
>>>       
>> yea it really dont look right, it look like it for some reason map the 
>> whole memory up untill the bios to the kernel as memory
>> it even map it on the pci hole so...
>> hrmmm, very weird,
>>
>> what is your host info (32/64 amd/intel kernel...)?
>>     
>
> 64-bit intel host, kernel 2.6.24-rc5
>
> Running kvm's current git userspace with modules from the same version.
>
>   
>> and what is the 
>> guest info (kernel 32/64...) ?
>>     
>
> 32-bit 2.6.23-rc6-mm1
>
>   
>> and what happen if you run it with -no-kvm ?
>>     
>
> Both current -git and kvm-44 seem to lock up at early kernel boot before
> even early printk is available.  But, GRUB comes up in both cases. 
>
> -no-kvm doesn't seem to change things at all.
>
> -- Dave
>
>   
when you see the grub how much memory is it saying you have?
how can i get the image that you are using?
(i dont know if it will be too much to ask, but if you run it with pure 
qemu (from qemu.org) is it working?)

for some reason the e820 return a really false values for your guest...
i would have suggest to check if you have the latest kvm bios(not in 
your physical computer bios) but it cannot be the problem as that you 
dont run it with more than 3.something giga...

i am going to sleep now, i will look at this tomorrow (this is strange)

thanks for reporting

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

Re: Slow Kernel Boot

[Dave Hansen]

On Tue, 2008-01-08 at 00:46 +0200, Izik Eidus wrote:
> Dave Hansen wrote:
> > On Tue, 2008-01-08 at 00:16 +0200, Izik Eidus wrote:
> >   
> >> 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
> >>> sections is basically from 0x100000 up to ~4G and *usable*.  That
> >>> doesn't look right.
> >>>   
> >>>       
> >> yea it really dont look right, it look like it for some reason map the 
> >> whole memory up untill the bios to the kernel as memory
> >> it even map it on the pci hole so...
> >> hrmmm, very weird,
> >>
> >> what is your host info (32/64 amd/intel kernel...)?
> >>     
> >
> > 64-bit intel host, kernel 2.6.24-rc5
> >
> > Running kvm's current git userspace with modules from the same version.
> >
> >   
> >> and what is the 
> >> guest info (kernel 32/64...) ?
> >>     
> >
> > 32-bit 2.6.23-rc6-mm1
> >
> >   
> >> and what happen if you run it with -no-kvm ?
> >>     
> >
> > Both current -git and kvm-44 seem to lock up at early kernel boot before
> > even early printk is available.  But, GRUB comes up in both cases. 
> >
> > -no-kvm doesn't seem to change things at all.
> >
> > -- Dave
> >
> >   
> when you see the grub how much memory is it saying you have?

    GNU GRUB  version 0.97  (639K lower / 4193279K upper memory)

> how can i get the image that you are using?

The disk images?  I made them myself and I've been using them for quite
a while.  Probably a year or more.

> (i dont know if it will be too much to ask, but if you run it with pure 
> qemu (from qemu.org) is it working?)

Ahhh.  I'm using the ubuntu one, and it does the same thing.  I guess
that means I found a qemu bug.

> for some reason the e820 return a really false values for your guest...
> i would have suggest to check if you have the latest kvm bios(not in 
> your physical computer bios) but it cannot be the problem as that you 
> dont run it with more than 3.something giga...

Yeah, I just updated the BIOSes.  They're right out of KVM's git repo.

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

Re: Slow Kernel Boot

[Amit Shah]

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

Re: Slow Kernel Boot

[Amit Shah]

On Tuesday 08 January 2008 12:12:53 Amit Shah wrote:
> 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!

Just wrote this.

>From 575b4414314cdc5c8280cfbf1761a6d419dd7a40 Mon Sep 17 00:00:00 2001
From: Amit Shah <amit.shah-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Date: Tue, 8 Jan 2008 18:24:34 +0530
Subject: [PATCH] qemu: Add support for suffixes to the -m parameter

The -m parameter doesn't take suffixes like G or M currently
and it doesn't complain if such a suffix is given.

Add support for the G and M suffixes and update the usage
instructions appropriately.

Signed-off-by: Amit Shah <amit.shah-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
---
 qemu/vl.c |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/qemu/vl.c b/qemu/vl.c
index 0f023ac..114a84e 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -7927,7 +7927,9 @@ static void help(int exitcode)
 #ifdef TARGET_I386
            "-no-fd-bootchk  disable boot signature checking for floppy 
disks\n"
 #endif
-           "-m megs         set virtual RAM size to megs MB [default=%d]\n"
+           "-m size         set virtual RAM size to size megs [default=%d 
MB].\n"
+           "                Optional suffixes 'M' (megabyte) and 'G' 
(gigabyte)"
+                            " are supported\n"
            "-smp n          set the number of CPUs to 'n' [default=1]\n"
            "-nographic      disable graphical output and redirect serial I/Os 
to console\n"
            "-portrait       rotate graphical output 90 deg left (only PXA 
LCD)\n"
@@ -8858,7 +8860,26 @@ int main(int argc, char **argv)
                 help(0);
                 break;
             case QEMU_OPTION_m:
-                ram_size = (int64_t)atoi(optarg) * 1024 * 1024;
+                errno = 0;
+                ram_size = strtoul(optarg, &optarg, 0);
+                if (errno)
+                    help(1);
+                switch (*optarg) {
+                case 'G':
+                case 'g':
+                    ram_size *= 1024;
+                    /* fall through */
+                case 'M':
+                case 'm':
+                case '\0':
+                    ram_size *= 1024 * 1024;
+                    optarg++;
+                    break;
+                default:
+                    help(1);
+                    break;
+                }
+
                 if (ram_size <= 0)
                     help(1);
                 if (ram_size > PHYS_RAM_MAX_SIZE) {
-- 
1.5.2.5



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

Re: Slow Kernel Boot

[Izik Eidus]

On Tue, 2008-01-08 at 18:31 +0530, Amit Shah wrote:
> On Tuesday 08 January 2008 12:12:53 Amit Shah wrote:
> > 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!
> 
> Just wrote this.
> 
> From 575b4414314cdc5c8280cfbf1761a6d419dd7a40 Mon Sep 17 00:00:00 2001
> From: Amit Shah <amit.shah-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
> Date: Tue, 8 Jan 2008 18:24:34 +0530
> Subject: [PATCH] qemu: Add support for suffixes to the -m parameter
> 
> The -m parameter doesn't take suffixes like G or M currently
> and it doesn't complain if such a suffix is given.
> 
> Add support for the G and M suffixes and update the usage
> instructions appropriately.
> 
> Signed-off-by: Amit Shah <amit.shah-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
> ---
>  qemu/vl.c |   25 +++++++++++++++++++++++--
>  1 files changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/qemu/vl.c b/qemu/vl.c
> index 0f023ac..114a84e 100644
> --- a/qemu/vl.c
> +++ b/qemu/vl.c
> @@ -7927,7 +7927,9 @@ static void help(int exitcode)
>  #ifdef TARGET_I386
>             "-no-fd-bootchk  disable boot signature checking for floppy 
> disks\n"
>  #endif
> -           "-m megs         set virtual RAM size to megs MB [default=%d]\n"
> +           "-m size         set virtual RAM size to size megs [default=%d 
> MB].\n"
> +           "                Optional suffixes 'M' (megabyte) and 'G' 
> (gigabyte)"
> +                            " are supported\n"
>             "-smp n          set the number of CPUs to 'n' [default=1]\n"
>             "-nographic      disable graphical output and redirect serial I/Os 
> to console\n"
>             "-portrait       rotate graphical output 90 deg left (only PXA 
> LCD)\n"
> @@ -8858,7 +8860,26 @@ int main(int argc, char **argv)
>                  help(0);
>                  break;
>              case QEMU_OPTION_m:
> -                ram_size = (int64_t)atoi(optarg) * 1024 * 1024;
> +                errno = 0;
> +                ram_size = strtoul(optarg, &optarg, 0);
> +                if (errno)
> +                    help(1);
> +                switch (*optarg) {
> +                case 'G':
> +                case 'g':
> +                    ram_size *= 1024;
> +                    /* fall through */
> +                case 'M':
> +                case 'm':
> +                case '\0':
> +                    ram_size *= 1024 * 1024;
> +                    optarg++;
> +                    break;
> +                default:
> +                    help(1);
> +                    break;
> +                }
> +
>                  if (ram_size <= 0)
>                      help(1);
>                  if (ram_size > PHYS_RAM_MAX_SIZE) {
i guess you should send it to qemu-devel, and then it will be merged to
kvm from there


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

Re: Slow Kernel Boot

[Amit Shah]

[-- Attachment #1: Type: text/plain, Size: 4237 bytes --]

On Tuesday 08 January 2008 18:31:53 Amit Shah wrote:
> On Tuesday 08 January 2008 12:12:53 Amit Shah wrote:
> > 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!
>
> Just wrote this.

CC qemu-devel and fix warning.

From f6da5a80d06fe33832c6210da95a2d031c5e67b9 Mon Sep 17 00:00:00 2001
From: Amit Shah <amit.shah-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Date: Tue, 8 Jan 2008 18:24:34 +0530
Subject: [PATCH] qemu: Add support for suffixes to the -m parameter

The -m parameter doesn't take suffixes like G or M currently
and it doesn't complain if such a suffix is given.

Add support for the G and M suffixes and update the usage
instructions appropriately.

Signed-off-by: Amit Shah <amit.shah-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
---
 qemu/vl.c |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/qemu/vl.c b/qemu/vl.c
index 0f023ac..2ed2469 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -7927,7 +7927,9 @@ static void help(int exitcode)
 #ifdef TARGET_I386
            "-no-fd-bootchk  disable boot signature checking for floppy 
disks\n"
 #endif
-           "-m megs         set virtual RAM size to megs MB [default=%d]\n"
+           "-m size         set virtual RAM size to size megs [default=%d 
MB].\n"
+           "                Optional suffixes 'M' (megabyte) and 'G' 
(gigabyte)"
+                            " are supported\n"
            "-smp n          set the number of CPUs to 'n' [default=1]\n"
            "-nographic      disable graphical output and redirect serial I/Os 
to console\n"
            "-portrait       rotate graphical output 90 deg left (only PXA 
LCD)\n"
@@ -8858,7 +8860,26 @@ int main(int argc, char **argv)
                 help(0);
                 break;
             case QEMU_OPTION_m:
-                ram_size = (int64_t)atoi(optarg) * 1024 * 1024;
+                errno = 0;
+                ram_size = (uint64_t) strtoul(optarg, (char **)&optarg, 0);
+                if (errno)
+                    help(1);
+                switch (*optarg) {
+                case 'G':
+                case 'g':
+                    ram_size *= 1024;
+                    /* fall through */
+                case 'M':
+                case 'm':
+                case '\0':
+                    ram_size *= 1024 * 1024;
+                    optarg++;
+                    break;
+                default:
+                    help(1);
+                    break;
+                }
+
                 if (ram_size <= 0)
                     help(1);
                 if (ram_size > PHYS_RAM_MAX_SIZE) {
-- 
1.5.2.5


[-- Attachment #2: 0001-qemu-Add-support-for-suffixes-to-the-m-parameter.patch --]
[-- Type: text/x-diff, Size: 2442 bytes --]

From f6da5a80d06fe33832c6210da95a2d031c5e67b9 Mon Sep 17 00:00:00 2001
From: Amit Shah <amit.shah-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
Date: Tue, 8 Jan 2008 18:24:34 +0530
Subject: [PATCH] qemu: Add support for suffixes to the -m parameter

The -m parameter doesn't take suffixes like G or M currently
and it doesn't complain if such a suffix is given.

Add support for the G and M suffixes and update the usage
instructions appropriately.

Signed-off-by: Amit Shah <amit.shah-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
---
 qemu/vl.c |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/qemu/vl.c b/qemu/vl.c
index 0f023ac..2ed2469 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -7927,7 +7927,9 @@ static void help(int exitcode)
 #ifdef TARGET_I386
            "-no-fd-bootchk  disable boot signature checking for floppy disks\n"
 #endif
-           "-m megs         set virtual RAM size to megs MB [default=%d]\n"
+           "-m size         set virtual RAM size to size megs [default=%d MB].\n"
+           "                Optional suffixes 'M' (megabyte) and 'G' (gigabyte)"
+                            " are supported\n"
            "-smp n          set the number of CPUs to 'n' [default=1]\n"
            "-nographic      disable graphical output and redirect serial I/Os to console\n"
            "-portrait       rotate graphical output 90 deg left (only PXA LCD)\n"
@@ -8858,7 +8860,26 @@ int main(int argc, char **argv)
                 help(0);
                 break;
             case QEMU_OPTION_m:
-                ram_size = (int64_t)atoi(optarg) * 1024 * 1024;
+                errno = 0;
+                ram_size = (uint64_t) strtoul(optarg, (char **)&optarg, 0);
+                if (errno)
+                    help(1);
+                switch (*optarg) {
+                case 'G':
+                case 'g':
+                    ram_size *= 1024;
+                    /* fall through */
+                case 'M':
+                case 'm':
+                case '\0':
+                    ram_size *= 1024 * 1024;
+                    optarg++;
+                    break;
+                default:
+                    help(1);
+                    break;
+                }
+
                 if (ram_size <= 0)
                     help(1);
                 if (ram_size > PHYS_RAM_MAX_SIZE) {
-- 
1.5.2.5


[-- Attachment #3: Type: text/plain, Size: 278 bytes --]

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

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: Slow Kernel Boot

[Dave Hansen]

On Tue, 2008-01-08 at 12:12 +0530, Amit Shah wrote:
> > 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!

OK.  Here's a function stolen blatantly from the kernel.  Seems to work
OK for me for:

	-m 1234
	-m 1234M
	-m 1G
	-m 99G

diff -ru orig/qemu-0.9.1/vl.c qemu-0.9.1/vl.c
--- orig/qemu-0.9.1/vl.c	2008-01-06 11:38:42.000000000 -0800
+++ qemu-0.9.1/vl.c	2008-01-08 11:23:29.000000000 -0800
@@ -8052,6 +8052,47 @@
 }
 #endif
 
+/**
+ *	memparse - parse a string with mem suffixes into a number of bytes
+ *	@ptr: Where parse begins
+ *
+ *	Parses a string into a number.  The number stored at @ptr is
+ *	potentially suffixed with %M (for megabytes, or 1048576 bytes)
+ *	or %G (for gigabytes, or 1073741824).  If the number is
+ *	suffixed with M or G, then the return value is the number
+ *	multiplied by one megabyte or one gigabyte, respectively. No
+ *	suffix implies megabytes.
+ */
+
+unsigned long long memparse (const char *ptr)
+{
+	char *endptr;
+	unsigned long ret = strtoull(ptr, &endptr, 0);
+
+	switch (*endptr) {
+	case 'G':
+	case 'g':
+		ret <<= 10;
+	case 'M':
+	case 'm':
+		ret <<= 20;
+		break;
+	default:
+		/* for backward compatibility; qemu has
+		 * traditionally taken this in plain MB */
+		ret <<= 20;
+		break;
+	}
+	if (ret <= 0)
+        	help(1);
+	if (ret > PHYS_RAM_MAX_SIZE) {
+		fprintf(stderr, "qemu: at most %d MB RAM can be simulated\n",
+			PHYS_RAM_MAX_SIZE / (1024 * 1024));
+		exit(1);
+	}
+	return ret;
+}
+
 #define MAX_NET_CLIENTS 32
 
 int main(int argc, char **argv)
@@ -8402,14 +8443,7 @@
                 help(0);
                 break;
             case QEMU_OPTION_m:
-                ram_size = atoi(optarg) * 1024 * 1024;
-                if (ram_size <= 0)
-                    help(1);
-                if (ram_size > PHYS_RAM_MAX_SIZE) {
-                    fprintf(stderr, "qemu: at most %d MB RAM can be simulated\n",
-                            PHYS_RAM_MAX_SIZE / (1024 * 1024));
-                    exit(1);
-                }
+                ram_size = memparse(optarg);
                 break;
             case QEMU_OPTION_d:
                 {
@@ -8664,6 +8698,7 @@
             }
         }
     }
+    fprintf(stderr, "qemu: using %d MB RAM\n", ram_size>>20);
 
 #ifndef _WIN32
     if (daemonize && !nographic && vnc_display == NULL) {


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

Re: Slow Kernel Boot

[Daniel P. Berrange]

On Tue, Jan 08, 2008 at 11:13:08AM -0800, Dave Hansen wrote:
> On Tue, 2008-01-08 at 12:12 +0530, Amit Shah wrote:
> > > 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!
> 
> OK.  Here's a function stolen blatantly from the kernel.  Seems to work

What license was this under originally ? The kernel is typically GPLv2,
while QEMU's core infrastructure is BSD (only some device emulation
is GPL). So not a good idea if you want this to go into upstream QEMU.

> --- orig/qemu-0.9.1/vl.c	2008-01-06 11:38:42.000000000 -0800
> +++ qemu-0.9.1/vl.c	2008-01-08 11:23:29.000000000 -0800
> @@ -8052,6 +8052,47 @@
>  }
>  #endif
>  
> +/**
> + *	memparse - parse a string with mem suffixes into a number of bytes
> + *	@ptr: Where parse begins
> + *
> + *	Parses a string into a number.  The number stored at @ptr is
> + *	potentially suffixed with %M (for megabytes, or 1048576 bytes)
> + *	or %G (for gigabytes, or 1073741824).  If the number is
> + *	suffixed with M or G, then the return value is the number
> + *	multiplied by one megabyte or one gigabyte, respectively. No
> + *	suffix implies megabytes.
> + */
> +
> +unsigned long long memparse (const char *ptr)
> +{
> +	char *endptr;
> +	unsigned long ret = strtoull(ptr, &endptr, 0);

32-bit overflow here on i686. Should be  unsigned long long if 
you want to support > 2 G on a 32-bit platform.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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