Skip to contentSkip to conversation

Fix segfault with ram_size > 4095M without kvm

PATCH In review Ryan Harper 4 participants 9 messages Feb 23, 2010 – Mar 6, 2010 KVM

lore
Share & tools
lore

Ryan Harper

author
#0 lore raw

PATCH 1/1 Fix segfault with ram_size > 4095M without kvm

Currently, x86_64-softmmu qemu segfaults when trying to use > 4095M memsize. This patch adds a simple check and error message (much like the 2047 limit on 32-bit hosts) on ram_size in the control path after we determine we're not using kvm

Upstream qemu-kvm is affected if using the -no-kvm option; this patch address the segfault there as well.

Signed-off-by Ryan Harper <[email protected]>
---
 vl.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)
vl.c +6 -0
index db7a178..a659e98 100644
@@ -5760,6 +5760,12 @@ int main(int argc, char **argv, char **envp)
             fprintf(stderr, "failed to initialize KVM\n");
             exit(1);
         }
+    } else {
+        /* without kvm enabled, we can only support 4095 MB RAM */
+        if (ram_size > (4095UL << 20)) {
+            fprintf(stderr, "qemu: without kvm support at most 4095 MB RAM can be simulated\n");
+            exit(1);
+        }
     }
 
     if (qemu_init_main_loop()) {
Signature · 8 lines
1.6.3.3


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
[email protected]
#1 lore raw
Quoted 7 lines · Ryan Harper

Currently, x86_64-softmmu qemu segfaults when trying to use > 4095M memsize. This patch adds a simple check and error message (much like the 2047 limit on 32-bit hosts) on ram_size in the control path after we determine we're not using kvm

Upstream qemu-kvm is affected if using the -no-kvm option; this patch address the segfault there as well.

It looks like workarounding the real bug. At some point both i386-softmmu (via PAE) and x86_64-softmmu were able to support > 4GB of memory. I remember adding the support long time ago, and testing it with 32GB of emulated RAM.

Quoted 22 lines
Signed-off-by Ryan Harper <[email protected]>
---
 vl.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)
vl.c +6 -0
index db7a178..a659e98 100644
@@ -5760,6 +5760,12 @@ int main(int argc, char **argv, char **envp)
             fprintf(stderr, "failed to initialize KVM\n");
             exit(1);
         }
+    } else {
+        /* without kvm enabled, we can only support 4095 MB RAM */
+        if (ram_size > (4095UL << 20)) {
+            fprintf(stderr, "qemu: without kvm support at most 4095 MB RAM can be simulated\n");
+            exit(1);
+        }
     }
 
     if (qemu_init_main_loop()) {
Signature · 2 lines
Aurelien Jarno                          GPG: 1024D/F1BCDB73
[email protected]                 http://www.aurel32.net
#2 lore raw
Quoted 6 lines · Aurelien Jarno
Quoted 5 lines · Ryan Harper

Currently, x86_64-softmmu qemu segfaults when trying to use > 4095M memsize. This patch adds a simple check and error message (much like the 2047 limit on 32-bit hosts) on ram_size in the control path after we determine we're not using kvm

Quoted 7 lines
Quoted 2 lines

Upstream qemu-kvm is affected if using the -no-kvm option; this patch address the segfault there as well.

It looks like workarounding the real bug. At some point both i386-softmmu (via PAE) and x86_64-softmmu were able to support > 4GB of memory. I remember adding the support long time ago, and testing it with 32GB of emulated RAM.

Sounds like a perfect candidate for -stable then. For HEAD I agree that finding the cause would be the way to go.

Alex

#3 lore raw
Quoted 13 lines · Alexander Graf
Quoted 10 lines · Aurelien Jarno
Quoted 8 lines · Ryan Harper

Currently, x86_64-softmmu qemu segfaults when trying to use> 4095M memsize. This patch adds a simple check and error message (much like the 2047 limit on 32-bit hosts) on ram_size in the control path after we determine we're not using kvm

Upstream qemu-kvm is affected if using the -no-kvm option; this patch address the segfault there as well.

Quoted 7 lines
Quoted 5 lines

It looks like workarounding the real bug. At some point both i386-softmmu (via PAE) and x86_64-softmmu were able to support> 4GB of memory. I remember adding the support long time ago, and testing it with 32GB of emulated RAM.

Sounds like a perfect candidate for -stable then. For HEAD I agree that finding the cause would be the way to go.

No, it's wrong. A good candidate for -stable would be something that fixes the SEGV :-)

Regards,

Anthony Liguori

Quoted 5 lines

Alex--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw
Quoted 11 lines · Anthony Liguori
Quoted 10 lines · Alexander Graf
Quoted 8 lines · Aurelien Jarno
Quoted 7 lines · Ryan Harper

Currently, x86_64-softmmu qemu segfaults when trying to use> 4095M memsize. This patch adds a simple check and error message (much like the 2047 limit on 32-bit hosts) on ram_size in the control path after we determine we're not using kvm

Upstream qemu-kvm is affected if using the -no-kvm option; this patch address the segfault there as well.

Quoted 9 lines
Quoted 5 lines
Quoted 4 lines

It looks like workarounding the real bug. At some point both i386-softmmu (via PAE) and x86_64-softmmu were able to support> 4GB of memory. I remember adding the support long time ago, and testing it with 32GB of emulated RAM.

Sounds like a perfect candidate for -stable then. For HEAD I agree that finding the cause would be the way to go.

No, it's wrong. A good candidate for -stable would be something that fixes the SEGV :-)

It actually depends on the patch and how invasive it is.

I'll bisect that later this week. For now what I can say it hasn't worked for a lot of time. It works in 0.9.1, but not in 0.10.0. It probably hasn't been noticed due to kqemu which was limiting the size to 2GB.

Signature · 2 lines
Aurelien Jarno                          GPG: 1024D/F1BCDB73
[email protected]                 http://www.aurel32.net
author
#5 lore raw
In reply to Aurelien Jarno
Quoted 6 lines · Aurelien Jarno
Quoted 5 lines · Ryan Harper

Currently, x86_64-softmmu qemu segfaults when trying to use > 4095M memsize. This patch adds a simple check and error message (much like the 2047 limit on 32-bit hosts) on ram_size in the control path after we determine we're not using kvm

Quoted 7 lines
Quoted 2 lines

Upstream qemu-kvm is affected if using the -no-kvm option; this patch address the segfault there as well.

It looks like workarounding the real bug. At some point both i386-softmmu (via PAE) and x86_64-softmmu were able to support > 4GB of memory. I remember adding the support long time ago, and testing it with 32GB of emulated RAM.

Indeed it was a workaround. I thought it was reasonable since we cap the size for 32-bit at 2047; but Anthony mentioned that on 64-bit hosts some targets had >4G support so we should fix the segfault. here is the backtrace I got from the core file:

Core was generated by `./x86_64-softmmu/qemu-system-x86_64 -m 4096'. Program terminated with signal 11, Segmentation fault.
#0 0x00000000004d1a59 in tb_alloc_page (tb=0x7f33d111d010, n=0, page_addr=4295094272)

    at /home/rharper/work/git/qemu/exec.c:1125
1125        tb->page_next[n] = p->first_tb;
(gdb) bt
#0  0x00000000004d1a59 in tb_alloc_page (tb=0x7f33d111d010, n=0, page_addr=4295094272)
    at /home/rharper/work/git/qemu/exec.c:1125
#1  0x00000000004d1bf1 in tb_link_phys (tb=0x7f33d111d010, phys_pc=4295098352, phys_page2=18446744073709551615)
    at /home/rharper/work/git/qemu/exec.c:1215
#2  0x00000000004d1612 in tb_gen_code (env=0x2180ed0, pc=4294967280, cs_base=4294901760, flags=68, cflags=0)
    at /home/rharper/work/git/qemu/exec.c:913
#3  0x00000000004d849c in tb_find_slow (pc=4294967280, cs_base=4294901760, flags=68)
    at /home/rharper/work/git/qemu/cpu-exec.c:161
#4  0x00000000004d85b2 in tb_find_fast () at /home/rharper/work/git/qemu/cpu-exec.c:182
#5  0x00000000004d8cdc in cpu_x86_exec (env1=0x2180ed0) at /home/rharper/work/git/qemu/cpu-exec.c:579
#6  0x000000000040d686 in qemu_cpu_exec (env=0x2180ed0) at /home/rharper/work/git/qemu/vl.c:3895
#7  0x000000000040d76b in tcg_cpu_exec () at /home/rharper/work/git/qemu/vl.c:3924
#8  0x000000000040da39 in main_loop () at /home/rharper/work/git/qemu/vl.c:4042
#9  0x0000000000411a2f in main (argc=3, argv=0x7fff5782ab08, envp=0x7fff5782ab28)
    at /home/rharper/work/git/qemu/vl.c:6102
Quoted 33 lines
Quoted 24 lines
Signed-off-by Ryan Harper <[email protected]>
---
 vl.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)
vl.c +6 -0
index db7a178..a659e98 100644
@@ -5760,6 +5760,12 @@ int main(int argc, char **argv, char **envp)
             fprintf(stderr, "failed to initialize KVM\n");
             exit(1);
         }
+    } else {
+        /* without kvm enabled, we can only support 4095 MB RAM */
+        if (ram_size > (4095UL << 20)) {
+            fprintf(stderr, "qemu: without kvm support at most 4095 MB RAM can be simulated\n");
+            exit(1);
+        }
     }
 
     if (qemu_init_main_loop()) {
Signature · 6 lines
Aurelien Jarno                          GPG: 1024D/F1BCDB73
[email protected]                 http://www.aurel32.net
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Signature · 4 lines
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
[email protected]
#6 lore raw
In reply to Aurelien Jarno
Quoted 6 lines · Aurelien Jarno
Quoted 5 lines · Ryan Harper

Currently, x86_64-softmmu qemu segfaults when trying to use > 4095M memsize. This patch adds a simple check and error message (much like the 2047 limit on 32-bit hosts) on ram_size in the control path after we determine we're not using kvm

Quoted 7 lines
Quoted 2 lines

Upstream qemu-kvm is affected if using the -no-kvm option; this patch address the segfault there as well.

It looks like workarounding the real bug. At some point both i386-softmmu (via PAE) and x86_64-softmmu were able to support > 4GB of memory. I remember adding the support long time ago, and testing it with 32GB of emulated RAM.

I have looked into that, and actually one patch to get full support for

Quoted 1 line

4GB of memory was not merged:

exec.c +1 -1
index 8389c54..b0bb058 100644
@@ -166,7 +166,7 @@ typedef struct PhysPageDesc {
  */
 #define L1_BITS (TARGET_VIRT_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS)
 #else
-#define L1_BITS (32 - L2_BITS - TARGET_PAGE_BITS)
+#define L1_BITS (TARGET_PHYS_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS)
 #endif
 
 #define L1_SIZE (1 << L1_BITS)

While this patch is acceptable for qemu i386, it creates a big L1 table for x86_64 or other 64-bit architectures, resulting in huge memory overhead.

The recent multilevel tables patches from Richard Henderson should fix the problem for HEAD (I haven't found time to look at them in details).

As this is not something we really want to backport, your patch makes sense in stable-0.12.

Quoted 30 lines
Quoted 22 lines
Signed-off-by Ryan Harper <[email protected]>
---
 vl.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)
vl.c +6 -0
index db7a178..a659e98 100644
@@ -5760,6 +5760,12 @@ int main(int argc, char **argv, char **envp)
             fprintf(stderr, "failed to initialize KVM\n");
             exit(1);
         }
+    } else {
+        /* without kvm enabled, we can only support 4095 MB RAM */
+        if (ram_size > (4095UL << 20)) {
+            fprintf(stderr, "qemu: without kvm support at most 4095 MB RAM can be simulated\n");
+            exit(1);
+        }
     }
 
     if (qemu_init_main_loop()) {
Signature · 2 lines
Aurelien Jarno                          GPG: 1024D/F1BCDB73
[email protected]                 http://www.aurel32.net
Signature · 2 lines
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
[email protected]                 http://www.aurel32.net
author
#7 lore raw
Quoted 10 lines · Aurelien Jarno
Quoted 9 lines · Aurelien Jarno
Quoted 7 lines · Ryan Harper

Currently, x86_64-softmmu qemu segfaults when trying to use > 4095M memsize. This patch adds a simple check and error message (much like the 2047 limit on 32-bit hosts) on ram_size in the control path after we determine we're not using kvm

Upstream qemu-kvm is affected if using the -no-kvm option; this patch address the segfault there as well.

Quoted 7 lines
Quoted 4 lines

It looks like workarounding the real bug. At some point both i386-softmmu (via PAE) and x86_64-softmmu were able to support > 4GB of memory. I remember adding the support long time ago, and testing it with 32GB of emulated RAM.

I have looked into that, and actually one patch to get full support for

Quoted 1 line

4GB of memory was not merged:

Thanks for looking into this.

Quoted 19 lines
exec.c +1 -1
index 8389c54..b0bb058 100644
@@ -166,7 +166,7 @@ typedef struct PhysPageDesc {
  */
 #define L1_BITS (TARGET_VIRT_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS)
 #else
-#define L1_BITS (32 - L2_BITS - TARGET_PAGE_BITS)
+#define L1_BITS (TARGET_PHYS_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS)
 #endif
 
 #define L1_SIZE (1 << L1_BITS)

While this patch is acceptable for qemu i386, it creates a big L1 table for x86_64 or other 64-bit architectures, resulting in huge memory overhead.

Quoted 5 lines

The recent multilevel tables patches from Richard Henderson should fix the problem for HEAD (I haven't found time to look at them in details).

As this is not something we really want to backport, your patch makes sense in stable-0.12.

Anthony, do you want me to resend and rebase against 0.12-stable?

Signature · 4 lines
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
[email protected]
#8 lore raw
Quoted 40 lines · Ryan Harper
Quoted 10 lines · Aurelien Jarno
Quoted 9 lines · Aurelien Jarno
Quoted 7 lines · Ryan Harper

Currently, x86_64-softmmu qemu segfaults when trying to use > 4095M memsize. This patch adds a simple check and error message (much like the 2047 limit on 32-bit hosts) on ram_size in the control path after we determine we're not using kvm

Upstream qemu-kvm is affected if using the -no-kvm option; this patch address the segfault there as well.

Quoted 7 lines
Quoted 4 lines

It looks like workarounding the real bug. At some point both i386-softmmu (via PAE) and x86_64-softmmu were able to support > 4GB of memory. I remember adding the support long time ago, and testing it with 32GB of emulated RAM.

I have looked into that, and actually one patch to get full support for

Quoted 1 line

4GB of memory was not merged:

Thanks for looking into this.

Quoted 19 lines
exec.c +1 -1
index 8389c54..b0bb058 100644
@@ -166,7 +166,7 @@ typedef struct PhysPageDesc {
  */
 #define L1_BITS (TARGET_VIRT_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS)
 #else
-#define L1_BITS (32 - L2_BITS - TARGET_PAGE_BITS)
+#define L1_BITS (TARGET_PHYS_ADDR_SPACE_BITS - L2_BITS - TARGET_PAGE_BITS)
 #endif
 
 #define L1_SIZE (1 << L1_BITS)

While this patch is acceptable for qemu i386, it creates a big L1 table for x86_64 or other 64-bit architectures, resulting in huge memory overhead.

Quoted 8 lines
Quoted 5 lines

The recent multilevel tables patches from Richard Henderson should fix the problem for HEAD (I haven't found time to look at them in details).

As this is not something we really want to backport, your patch makes sense in stable-0.12.

Anthony, do you want me to resend and rebase against 0.12-stable?

The patch applies correctly on stable-0.12. I have just applied it.

Signature · 2 lines
Aurelien Jarno                          GPG: 1024D/F1BCDB73
[email protected]                 http://www.aurel32.net