[PATCH] Fix segfault with ram_size > 4095M without kvm

[PATCH] Fix segfault with ram_size > 4095M without kvm

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

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()) {
-- 
1.6.3.3


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com

Re: [PATCH] Fix segfault with ram_size > 4095M without kvm

[Aurelien Jarno]

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()) {


-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm

[Alexander Graf]

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

Re: [Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm

[Anthony Liguori]

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
>    

Re: [Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm

[Aurelien Jarno]

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                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm

[Ryan Harper]

* 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

-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com

Re: [Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm

[Aurelien Jarno]

On Tue, Feb 23, 2010 at 06:02:15PM +0100, 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.

I have looked into that, and actually one patch to get full support for
 > 4GB of memory was not merged:

diff --git a/exec.c b/exec.c
index 8389c54..b0bb058 100644
--- a/exec.c
+++ b/exec.c
@@ -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.


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

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm

[Ryan Harper]

* Aurelien Jarno <aurelien@aurel32.net> [2010-03-04 15:27]:
> On Tue, Feb 23, 2010 at 06:02:15PM +0100, 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.
> 
> I have looked into that, and actually one patch to get full support for
>  > 4GB of memory was not merged:

Thanks for looking into this.

> 
> diff --git a/exec.c b/exec.c
> index 8389c54..b0bb058 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -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.

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


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com

Re: [Qemu-devel] [PATCH] Fix segfault with ram_size > 4095M without kvm

[Aurelien Jarno]

On Thu, Mar 04, 2010 at 03:34:34PM -0600, Ryan Harper wrote:
> * Aurelien Jarno <aurelien@aurel32.net> [2010-03-04 15:27]:
> > On Tue, Feb 23, 2010 at 06:02:15PM +0100, 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.
> > 
> > I have looked into that, and actually one patch to get full support for
> >  > 4GB of memory was not merged:
> 
> Thanks for looking into this.
> 
> > 
> > diff --git a/exec.c b/exec.c
> > index 8389c54..b0bb058 100644
> > --- a/exec.c
> > +++ b/exec.c
> > @@ -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.
> 
> 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.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net