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

[Qemu-devel] [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: [Qemu-devel] [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

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

[Luiz Capitulino]

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>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
---
NOTE: this patch was applied in the v0.12.x branch, but it seems it got
      lost for master

 vl.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/vl.c b/vl.c
index 2dbb6db..bb9c21c 100644
--- a/vl.c
+++ b/vl.c
@@ -5792,6 +5792,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.7.3.3.402.ga48aa

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

[Anthony Liguori]

On 12/08/2010 12:01 PM, Luiz Capitulino wrote:
> 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>
> Signed-off-by: Aurelien Jarno<aurelien@aurel32.net>
> ---
> NOTE: this patch was applied in the v0.12.x branch, but it seems it got
>        lost for master
>    

No, it was intentional.  We should fix the segv, this is not a known 
limitation but rather a bug.

Regards,

Anthony Liguori

>   vl.c |    6 ++++++
>   1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/vl.c b/vl.c
> index 2dbb6db..bb9c21c 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -5792,6 +5792,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()) {
>    

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

[Luiz Capitulino]

On Wed, 08 Dec 2010 12:23:12 -0600
Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:

> On 12/08/2010 12:01 PM, Luiz Capitulino wrote:
> > 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>
> > Signed-off-by: Aurelien Jarno<aurelien@aurel32.net>
> > ---
> > NOTE: this patch was applied in the v0.12.x branch, but it seems it got
> >        lost for master
> >    
> 
> No, it was intentional.  We should fix the segv, this is not a known 
> limitation but rather a bug.

A TCG bug, I presume?

> 
> Regards,
> 
> Anthony Liguori
> 
> >   vl.c |    6 ++++++
> >   1 files changed, 6 insertions(+), 0 deletions(-)
> >
> > diff --git a/vl.c b/vl.c
> > index 2dbb6db..bb9c21c 100644
> > --- a/vl.c
> > +++ b/vl.c
> > @@ -5792,6 +5792,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()) {
> >    
> 

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

[Anthony Liguori]

On 12/08/2010 12:27 PM, Luiz Capitulino wrote:
> On Wed, 08 Dec 2010 12:23:12 -0600
> Anthony Liguori<aliguori@linux.vnet.ibm.com>  wrote:
>
>    
>> On 12/08/2010 12:01 PM, Luiz Capitulino wrote:
>>      
>>> 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>
>>> Signed-off-by: Aurelien Jarno<aurelien@aurel32.net>
>>> ---
>>> NOTE: this patch was applied in the v0.12.x branch, but it seems it got
>>>         lost for master
>>>
>>>        
>> No, it was intentional.  We should fix the segv, this is not a known
>> limitation but rather a bug.
>>      
> A TCG bug, I presume?
>    

Dunno, that's why we shouldn't just paper over it.

Regards,

Anthony Liguori

>    
>> Regards,
>>
>> Anthony Liguori
>>
>>      
>>>    vl.c |    6 ++++++
>>>    1 files changed, 6 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/vl.c b/vl.c
>>> index 2dbb6db..bb9c21c 100644
>>> --- a/vl.c
>>> +++ b/vl.c
>>> @@ -5792,6 +5792,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()) {
>>>
>>>        
>>      
>    

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

[Aurelien Jarno]

On Wed, Dec 08, 2010 at 04:27:45PM -0200, Luiz Capitulino wrote:
> On Wed, 08 Dec 2010 12:23:12 -0600
> Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:
> 
> > On 12/08/2010 12:01 PM, Luiz Capitulino wrote:
> > > 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>
> > > Signed-off-by: Aurelien Jarno<aurelien@aurel32.net>
> > > ---
> > > NOTE: this patch was applied in the v0.12.x branch, but it seems it got
> > >        lost for master
> > >    
> > 
> > No, it was intentional.  We should fix the segv, this is not a known 
> > limitation but rather a bug.
> 
> A TCG bug, I presume?
> 

Do you have more details about this issue and how to reproduce it? 

Support for more than 4GB of memory has been added a few years ago, 
and I am not able to reproduce the problem anymore (I have booted a 
64-bit guest with 6GB of RAM, and make sure the guest use the whole 
memory). I guess TCG itself is fine, but there might be a bug in
the MMU emulation in some cases.

I also noticed that now i386-softmmu has been artificially limited to
2047MB. Tthis configuration used to support up to 64GB of RAM (PAE)
on 64-bit hosts.

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

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

[Ryan Harper]

* Aurelien Jarno <aurelien@aurel32.net> [2010-12-25 16:37]:
> On Wed, Dec 08, 2010 at 04:27:45PM -0200, Luiz Capitulino wrote:
> > On Wed, 08 Dec 2010 12:23:12 -0600
> > Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:
> > 
> > > On 12/08/2010 12:01 PM, Luiz Capitulino wrote:
> > > > 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>
> > > > Signed-off-by: Aurelien Jarno<aurelien@aurel32.net>
> > > > ---
> > > > NOTE: this patch was applied in the v0.12.x branch, but it seems it got
> > > >        lost for master
> > > >    
> > > 
> > > No, it was intentional.  We should fix the segv, this is not a known 
> > > limitation but rather a bug.
> > 
> > A TCG bug, I presume?
> > 
> 
> Do you have more details about this issue and how to reproduce it? 

At the time of the bug, it was something simple like:

qemu-system-x86_64 -m 4097 -hda /dev/null

we'd get an imediate segfault.  As you say, I'm not seeing it now on
current git; I'll see about bisecting to see if we did get a fix for the
issue.

> 
> Support for more than 4GB of memory has been added a few years ago, 
> and I am not able to reproduce the problem anymore (I have booted a 
> 64-bit guest with 6GB of RAM, and make sure the guest use the whole 
> memory). I guess TCG itself is fine, but there might be a bug in
> the MMU emulation in some cases.
> 
> I also noticed that now i386-softmmu has been artificially limited to
> 2047MB. Tthis configuration used to support up to 64GB of RAM (PAE)
> on 64-bit hosts.
> 
> -- 
> Aurelien Jarno                          GPG: 1024D/F1BCDB73
> aurelien@aurel32.net                 http://www.aurel33.net

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

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

[Ryan Harper]

* Ryan Harper <ryanh@us.ibm.com> [2011-01-04 09:49]:
> * Aurelien Jarno <aurelien@aurel32.net> [2010-12-25 16:37]:
> > On Wed, Dec 08, 2010 at 04:27:45PM -0200, Luiz Capitulino wrote:
> > > On Wed, 08 Dec 2010 12:23:12 -0600
> > > Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:
> > > 
> > > > On 12/08/2010 12:01 PM, Luiz Capitulino wrote:
> > > > > 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>
> > > > > Signed-off-by: Aurelien Jarno<aurelien@aurel32.net>
> > > > > ---
> > > > > NOTE: this patch was applied in the v0.12.x branch, but it seems it got
> > > > >        lost for master
> > > > >    
> > > > 
> > > > No, it was intentional.  We should fix the segv, this is not a known 
> > > > limitation but rather a bug.
> > > 
> > > A TCG bug, I presume?
> > > 
> > 
> > Do you have more details about this issue and how to reproduce it? 
> 
> At the time of the bug, it was something simple like:
> 
> qemu-system-x86_64 -m 4097 -hda /dev/null
> 
> we'd get an imediate segfault.  As you say, I'm not seeing it now on
> current git; I'll see about bisecting to see if we did get a fix for the
> issue.

I attempted to bisect, but there a couple commits around where the issue
was fixed that broke git bisect =(  That narrowed it down to about 5
commits to check.

This the last git commit where I can reproduce the segfault with the
above test case (qemu invocation).

commit 0aef4261ac0ec9089ade0e3a92f986cb4ba7317e
Author: Aurelien Jarno <aurelien@aurel32.net>
Date:   Thu Mar 11 21:29:42 2010 +0100

    target-ppc: fix evsrwu and evsrws (second try)
    
    Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>


The next 4 commits don't compile so they are untest-able:

commit 14f24e1465edc44b9b4d89fbbea66e06088154e1
 - fails to build with:
    - ./configure --target-list=x86_64-softmmu && make clean && make
/home/rharper/work/git/qemu/exec.c: In function 'phys_page_find_alloc':
/home/rharper/work/git/qemu/exec.c:341: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
/home/rharper/work/git/qemu/exec.c: In function 'phys_page_for_each':
/home/rharper/work/git/qemu/exec.c:1670: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
make[1]: *** [exec.o] Error 1
make: *** [subdir-x86_64-softmmu] Error 2

commit 7bc7b099dfa38a856b1bc892c0f9f3d6fe28e170
 - fails to build with:
    - ./configure --target-list=x86_64-softmmu && make clean && make
/home/rharper/work/git/qemu/exec.c: In function 'phys_page_find_alloc':
/home/rharper/work/git/qemu/exec.c:341: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
/home/rharper/work/git/qemu/exec.c: In function 'phys_page_for_each':
/home/rharper/work/git/qemu/exec.c:1670: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
make[1]: *** [exec.o] Error 1
make: *** [subdir-x86_64-softmmu] Error 2

commit b9f83121a13153536d886305414b540460c34508
 - fails to build with:
    - ./configure --target-list=x86_64-softmmu && make clean && make
/home/rharper/work/git/qemu/exec.c: In function 'phys_page_find_alloc':
/home/rharper/work/git/qemu/exec.c:341: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
/home/rharper/work/git/qemu/exec.c: In function 'phys_page_for_each':
/home/rharper/work/git/qemu/exec.c:1670: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
make[1]: *** [exec.o] Error 1
make: *** [subdir-x86_64-softmmu] Error 2

commit 5270589032f450ae7c3448730855aa18ff68ccff
 - fails to build with:
    - ./configure --target-list=x86_64-softmmu && make clean && make
/home/rharper/work/git/qemu/exec.c: In function 'phys_page_find_alloc':
/home/rharper/work/git/qemu/exec.c:341: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
/home/rharper/work/git/qemu/exec.c: In function 'phys_page_for_each':
/home/rharper/work/git/qemu/exec.c:1670: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
make[1]: *** [exec.o] Error 1
make: *** [subdir-x86_64-softmmu] Error 2


And this commit compiles and the test case no longer segfaults.  So I'd
say things are fixed at this point.

commit 5cd2c5b6ad75c46d40118ac67c0c09d4e7930a65
- compiles and issue is no longer present.
    - ./configure --target-list=x86_64-softmmu && make clean && make &&
    sudo x86_64-softmmu/qemu-syem-x86_64 -L pc-bios -hda /dev/null -m 4097


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

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

[Aurelien Jarno]

On Wed, Jan 05, 2011 at 01:04:51PM -0600, Ryan Harper wrote:
> * Ryan Harper <ryanh@us.ibm.com> [2011-01-04 09:49]:
> > * Aurelien Jarno <aurelien@aurel32.net> [2010-12-25 16:37]:
> > > On Wed, Dec 08, 2010 at 04:27:45PM -0200, Luiz Capitulino wrote:
> > > > On Wed, 08 Dec 2010 12:23:12 -0600
> > > > Anthony Liguori <aliguori@linux.vnet.ibm.com> wrote:
> > > > 
> > > > > On 12/08/2010 12:01 PM, Luiz Capitulino wrote:
> > > > > > 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>
> > > > > > Signed-off-by: Aurelien Jarno<aurelien@aurel32.net>
> > > > > > ---
> > > > > > NOTE: this patch was applied in the v0.12.x branch, but it seems it got
> > > > > >        lost for master
> > > > > >    
> > > > > 
> > > > > No, it was intentional.  We should fix the segv, this is not a known 
> > > > > limitation but rather a bug.
> > > > 
> > > > A TCG bug, I presume?
> > > > 
> > > 
> > > Do you have more details about this issue and how to reproduce it? 
> > 
> > At the time of the bug, it was something simple like:
> > 
> > qemu-system-x86_64 -m 4097 -hda /dev/null
> > 
> > we'd get an imediate segfault.  As you say, I'm not seeing it now on
> > current git; I'll see about bisecting to see if we did get a fix for the
> > issue.
> 
> I attempted to bisect, but there a couple commits around where the issue
> was fixed that broke git bisect =(  That narrowed it down to about 5
> commits to check.
> 
> This the last git commit where I can reproduce the segfault with the
> above test case (qemu invocation).
> 
> commit 0aef4261ac0ec9089ade0e3a92f986cb4ba7317e
> Author: Aurelien Jarno <aurelien@aurel32.net>
> Date:   Thu Mar 11 21:29:42 2010 +0100
> 
>     target-ppc: fix evsrwu and evsrws (second try)
>     
>     Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
> 
> 
> The next 4 commits don't compile so they are untest-able:
> 
> commit 14f24e1465edc44b9b4d89fbbea66e06088154e1
>  - fails to build with:
>     - ./configure --target-list=x86_64-softmmu && make clean && make
> /home/rharper/work/git/qemu/exec.c: In function 'phys_page_find_alloc':
> /home/rharper/work/git/qemu/exec.c:341: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
> /home/rharper/work/git/qemu/exec.c: In function 'phys_page_for_each':
> /home/rharper/work/git/qemu/exec.c:1670: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
> make[1]: *** [exec.o] Error 1
> make: *** [subdir-x86_64-softmmu] Error 2
> 
> commit 7bc7b099dfa38a856b1bc892c0f9f3d6fe28e170
>  - fails to build with:
>     - ./configure --target-list=x86_64-softmmu && make clean && make
> /home/rharper/work/git/qemu/exec.c: In function 'phys_page_find_alloc':
> /home/rharper/work/git/qemu/exec.c:341: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
> /home/rharper/work/git/qemu/exec.c: In function 'phys_page_for_each':
> /home/rharper/work/git/qemu/exec.c:1670: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
> make[1]: *** [exec.o] Error 1
> make: *** [subdir-x86_64-softmmu] Error 2
> 
> commit b9f83121a13153536d886305414b540460c34508
>  - fails to build with:
>     - ./configure --target-list=x86_64-softmmu && make clean && make
> /home/rharper/work/git/qemu/exec.c: In function 'phys_page_find_alloc':
> /home/rharper/work/git/qemu/exec.c:341: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
> /home/rharper/work/git/qemu/exec.c: In function 'phys_page_for_each':
> /home/rharper/work/git/qemu/exec.c:1670: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
> make[1]: *** [exec.o] Error 1
> make: *** [subdir-x86_64-softmmu] Error 2
> 
> commit 5270589032f450ae7c3448730855aa18ff68ccff
>  - fails to build with:
>     - ./configure --target-list=x86_64-softmmu && make clean && make
> /home/rharper/work/git/qemu/exec.c: In function 'phys_page_find_alloc':
> /home/rharper/work/git/qemu/exec.c:341: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
> /home/rharper/work/git/qemu/exec.c: In function 'phys_page_for_each':
> /home/rharper/work/git/qemu/exec.c:1670: error: #error unsupported TARGET_PHYS_ADDR_SPACE_BITS
> make[1]: *** [exec.o] Error 1
> make: *** [subdir-x86_64-softmmu] Error 2
> 
> 
> And this commit compiles and the test case no longer segfaults.  So I'd
> say things are fixed at this point.
> 
> commit 5cd2c5b6ad75c46d40118ac67c0c09d4e7930a65
> - compiles and issue is no longer present.
>     - ./configure --target-list=x86_64-softmmu && make clean && make &&
>     sudo x86_64-softmmu/qemu-syem-x86_64 -L pc-bios -hda /dev/null -m 4097
> 

It's more likely this commit which fixes the bug.

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