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

2010-12-09 Thread 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 ry...@us.ibm.com
Signed-off-by: Aurelien Jarno aurel...@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

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

2010-03-06 Thread Aurelien Jarno 
On Thu, Mar 04, 2010 at 03:34:34PM -0600, Ryan Harper wrote:
 * Aurelien Jarno aurel...@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
aurel...@aurel32.net http://www.aurel32.net

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

2010-03-04 Thread 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 ry...@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
 aurel...@aurel32.net http://www.aurel32.net
 
 
 

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

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

2010-03-04 Thread Ryan Harper 
* Aurelien Jarno aurel...@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
ry...@us.ibm.com

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

2010-02-23 Thread 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 ry...@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
ry...@us.ibm.com

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

2010-02-23 Thread 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 ry...@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
aurel...@aurel32.net http://www.aurel32.net

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

2010-02-23 Thread 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

2010-02-23 Thread 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 majord...@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

2010-02-23 Thread 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
aurel...@aurel32.net http://www.aurel32.net

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

2010-02-23 Thread Ryan Harper 
* Aurelien Jarno aurel...@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  0x004d1a59 in tb_alloc_page (tb=0x7f33d111d010, n=0, 
page_addr=4295094272)
at /home/rharper/work/git/qemu/exec.c:1125
1125tb-page_next[n] = p-first_tb;
(gdb) bt
#0  0x004d1a59 in tb_alloc_page (tb=0x7f33d111d010, n=0, 
page_addr=4295094272)
at /home/rharper/work/git/qemu/exec.c:1125
#1  0x004d1bf1 in tb_link_phys (tb=0x7f33d111d010, phys_pc=4295098352, 
phys_page2=18446744073709551615)
at /home/rharper/work/git/qemu/exec.c:1215
#2  0x004d1612 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  0x004d849c in tb_find_slow (pc=4294967280, cs_base=4294901760, 
flags=68)
at /home/rharper/work/git/qemu/cpu-exec.c:161
#4  0x004d85b2 in tb_find_fast () at 
/home/rharper/work/git/qemu/cpu-exec.c:182
#5  0x004d8cdc in cpu_x86_exec (env1=0x2180ed0) at 
/home/rharper/work/git/qemu/cpu-exec.c:579
#6  0x0040d686 in qemu_cpu_exec (env=0x2180ed0) at 
/home/rharper/work/git/qemu/vl.c:3895
#7  0x0040d76b in tcg_cpu_exec () at 
/home/rharper/work/git/qemu/vl.c:3924
#8  0x0040da39 in main_loop () at /home/rharper/work/git/qemu/vl.c:4042
#9  0x00411a2f in main (argc=3, argv=0x7fff5782ab08, 
envp=0x7fff5782ab28)
at /home/rharper/work/git/qemu/vl.c:6102


 
 
  Signed-off-by: Ryan Harper ry...@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
 aurel...@aurel32.net http://www.aurel32.net
 --
 To unsubscribe from this list: send the line unsubscribe kvm in
 the body of a message to majord...@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
ry...@us.ibm.com