Slow Kernel Boot

DISCUSSION Dave Hansen 4 participants 11 messages Jan 7, 2008 – Jan 8, 2008 4 messages not in the archive KVM

Share & tools

Dave Hansen

author

2008-01-07 22:05 UTC #0 lore raw

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

Izik Eidus

2008-01-07 22:16 UTC #1 lore raw

Quoted 26 lines · 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)

Quoted 4 lines

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

A message that is not in the archive (sent off-list or not yet received): 4782A4AF.6020902-atKUWr5tajBWk0Htik3J/[email protected]

Dave Hansen

author

2008-01-07 22:46 UTC #3 lore raw

Quoted 31 lines · Izik Eidus

Quoted 26 lines · 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)
Quoted 4 lines
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.

Quoted 6 lines

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.

Quoted 2 lines

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

32-bit 2.6.23-rc6-mm1

Quoted 1 line

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

Izik Eidus

2008-01-07 22:46 UTC #4 lore raw

Quoted 58 lines · Dave Hansen

Quoted 33 lines · Izik Eidus
Quoted 26 lines · 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)
Quoted 5 lines
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.
Quoted 7 lines
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.
Quoted 3 lines
and what is the
guest info (kernel 32/64...) ?
32-bit 2.6.23-rc6-mm1
Quoted 2 lines
and what happen if you run it with -no-kvm ?

Quoted 8 lines

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

A message that is not in the archive (sent off-list or not yet received): 4782ABCA.2090303-atKUWr5tajBWk0Htik3J/[email protected]

Dave Hansen

author

2008-01-07 23:03 UTC #6 lore raw

Quoted 62 lines · Izik Eidus

Quoted 61 lines · Dave Hansen
Quoted 33 lines · Izik Eidus
Quoted 26 lines · 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)
Quoted 5 lines
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.
Quoted 7 lines
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.
Quoted 3 lines
and what is the
guest info (kernel 32/64...) ?
32-bit 2.6.23-rc6-mm1
Quoted 2 lines
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.

Quoted 6 lines

Quoted 5 lines
-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)

Quoted 1 line

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.

Quoted 2 lines

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

Quoted 4 lines

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

Amit Shah

2008-01-08 06:42 UTC #7 lore raw

In reply to Dave Hansen

Quoted 19 lines · 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:

Quoted 8 lines

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!

Quoted 27 lines

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

Quoted 3 lines

Any idea how to debug this?
-- Dave

A message that is not in the archive (sent off-list or not yet received): 200801081212.53737.amit.shah-atKUWr5tajBWk0Htik3J/[email protected]

Amit Shah

2008-01-08 13:01 UTC #9 lore raw

Quoted 27 lines · On Tuesday 08 January 2008 12:12:53 Amit Shah wrote:

Quoted 26 lines · 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)

Quoted 7 lines

Quoted 1 line
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.

Quoted 1 line

From 575b4414314cdc5c8280cfbf1761a6d419dd7a40 Mon Sep 17 00:00:00 2001

From: Amit Shah <amit.shah-atKUWr5tajBWk0Htik3J/[email protected]>
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/[email protected]>

---
 qemu/vl.c |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

qemu/vl.c +0 -0

index 0f023ac..114a84e 100644
@@ -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) {

Signature · 9 lines

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

A message that is not in the archive (sent off-list or not yet received): 200801081831.54465.amit.shah-atKUWr5tajBWk0Htik3J/[email protected]

Izik Eidus

2008-01-08 12:54 UTC #11 lore raw

Quoted 92 lines · Amit Shah

Quoted 27 lines · On Tuesday 08 January 2008 12:12:53 Amit Shah wrote:
Quoted 26 lines · 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)
Quoted 7 lines
Quoted 1 line
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/[email protected]>
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/[email protected]>
---
 qemu/vl.c |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)
qemu/vl.c +0 -0
index 0f023ac..114a84e 100644
@@ -7927,7 +7927,9 @@ static void help(int exitcode)
 #ifdef TARGET_I386
            "-no-fd-bootchk  disable boot signature checking for floppy 
disks\n"
#endif
qemu/vl.c +1 -1
-           "-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"
qemu/vl.c +13 -1
@@ -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;

qemu/vl.c int main(int argc, char **argv) · line 8885

Quoted 10 lines

qemu/vl.c +7 -0

+                    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

Amit Shah

2008-01-08 13:18 UTC #12 lore raw

In reply to a message not in the archive

Quoted 30 lines · On Tuesday 08 January 2008 18:31:53 Amit Shah wrote:

Quoted 29 lines · On Tuesday 08 January 2008 12:12:53 Amit Shah wrote:
Quoted 27 lines · 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

Quoted 7 lines

Quoted 5 lines
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/[email protected]>
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/[email protected]>

---
 qemu/vl.c |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

qemu/vl.c +0 -0

index 0f023ac..2ed2469 100644
@@ -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) {

Signature · 1 line

1.5.2.5

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/[email protected]>

---
 qemu/vl.c |   25 +++++++++++++++++++++++--
 1 files changed, 23 insertions(+), 2 deletions(-)

qemu/vl.c +23 -2

index 0f023ac..2ed2469 100644
@@ -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) {

Signature · 1 line

1.5.2.5

_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Dave Hansen

author

2008-01-08 19:13 UTC #13 lore raw

In reply to a message not in the archive

Quoted 9 lines · Amit Shah

Quoted 8 lines
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

Quoted 7 lines

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

vl.c renamed from qemu-0.9.1/vl.c +43 -8

diff -ru orig/qemu-0.9.1/vl.c qemu-0.9.1/vl.c
@@ -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

Daniel P. Berrange

2008-01-08 19:26 UTC #14 lore raw

Quoted 14 lines · Dave Hansen

Quoted 13 lines · Amit Shah
Quoted 8 lines
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.

Quoted 5 lines

Quoted 3 lines
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.

Quoted 12 lines

vl.c renamed from qemu-0.9.1/vl.c +6 -0

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

vl.c line 8070

Quoted 10 lines

vl.c renamed from qemu-0.9.1/vl.c +10 -0

+ *	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.

Signature · 10 lines

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