| Message ID | 20100223151314.GN17350@us.ibm.com |
|---|---|
| State | New |
| Headers | show |
Ryan Harper a écrit : > 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. > Signed-off-by: Ryan Harper <ryanh@us.ibm.com> > --- > vl.c | 6 ++++++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/vl.c b/vl.c > index db7a178..a659e98 100644 > --- a/vl.c > +++ b/vl.c > @@ -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()) {
On 23.02.2010, at 18:02, Aurelien Jarno wrote: > Ryan Harper a écrit : >> 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. Sounds like a perfect candidate for -stable then. For HEAD I agree that finding the cause would be the way to go. Alex
On 02/23/2010 02:30 PM, Alexander Graf wrote: > On 23.02.2010, at 18:02, Aurelien Jarno wrote: > > >> Ryan Harper a écrit : >> >>> 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. >> > 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 > Alex-- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
On Tue, Feb 23, 2010 at 03:07:20PM -0600, Anthony Liguori wrote: > On 02/23/2010 02:30 PM, Alexander Graf wrote: > >On 23.02.2010, at 18:02, Aurelien Jarno wrote: > > > >>Ryan Harper a écrit : > >>>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. > >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.
* Aurelien Jarno <aurelien@aurel32.net> [2010-02-23 11:37]: > Ryan Harper a écrit : > > 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. 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 > > > > Signed-off-by: Ryan Harper <ryanh@us.ibm.com> > > --- > > vl.c | 6 ++++++ > > 1 files changed, 6 insertions(+), 0 deletions(-) > > > > diff --git a/vl.c b/vl.c > > index db7a178..a659e98 100644 > > --- a/vl.c > > +++ b/vl.c > > @@ -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()) { > > > -- > Aurelien Jarno GPG: 1024D/F1BCDB73 > aurelien@aurel32.net http://www.aurel32.net > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/vl.c b/vl.c index db7a178..a659e98 100644 --- a/vl.c +++ b/vl.c @@ -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()) {
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 <ryanh@us.ibm.com> --- vl.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-)