Fix for xen guest with mem > 3.7G

Fix for xen guest with mem > 3.7G

[Roberto De Ioris]

Xen domU kernel 2.6.26 and 2.6.27-rc cannot allocate
more than 3.7GB of ram on my PAE systems (compiled
with gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)).

I have found the problem is in function xen_memory_setup (in
arch/x86/xen/setup.c).

It set max_pfn as 'unsigned long' but add_memory_region()
takes 'unsigned long long'.

I do not know if it is a compiler problem but this is the simple fix
(works on my systems):

--- setup.c.orig	2008-09-13 21:12:56.000000000 +0200
+++ setup.c	2008-09-13 20:35:29.000000000 +0200
@@ -36,7 +36,7 @@
 
 char * __init xen_memory_setup(void)
 {
-	unsigned long max_pfn = xen_start_info->nr_pages;
+	unsigned long long max_pfn = xen_start_info->nr_pages;
 
 	e820.nr_map = 0;
 	add_memory_region(0, LOWMEMSIZE(), E820_RAM);



-- 
Roberto De Ioris
http://unbit.it
JID: roberto@jabber.unbit.it

Re: Fix for xen guest with mem > 3.7G

[Jeremy Fitzhardinge]

Roberto De Ioris wrote:
> Xen domU kernel 2.6.26 and 2.6.27-rc cannot allocate
> more than 3.7GB of ram on my PAE systems (compiled
> with gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)).
>
> I have found the problem is in function xen_memory_setup (in
> arch/x86/xen/setup.c).
>
> It set max_pfn as 'unsigned long' but add_memory_region()
> takes 'unsigned long long'.
>
> I do not know if it is a compiler problem but this is the simple fix
> (works on my systems):
>   

Thanks very much for the patch.  We have a more general fix for this in
Ingo's tip.git tree, but I overlooked that this particular problem
affected current -rc.

Ingo, this is fixed by the phys_addr_t + PFN_PHYS() patches.  Should we
send them up to Linus, or do an ad-hoc fix in this one place?

Thanks,
    J

> --- setup.c.orig	2008-09-13 21:12:56.000000000 +0200
> +++ setup.c	2008-09-13 20:35:29.000000000 +0200
> @@ -36,7 +36,7 @@
>  
>  char * __init xen_memory_setup(void)
>  {
> -	unsigned long max_pfn = xen_start_info->nr_pages;
> +	unsigned long long max_pfn = xen_start_info->nr_pages;
>  
>  	e820.nr_map = 0;
>  	add_memory_region(0, LOWMEMSIZE(), E820_RAM);
>
>
>
>   

Re: Fix for xen guest with mem > 3.7G

[Ingo Molnar]

* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> Roberto De Ioris wrote:
> > Xen domU kernel 2.6.26 and 2.6.27-rc cannot allocate
> > more than 3.7GB of ram on my PAE systems (compiled
> > with gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)).
> >
> > I have found the problem is in function xen_memory_setup (in
> > arch/x86/xen/setup.c).
> >
> > It set max_pfn as 'unsigned long' but add_memory_region()
> > takes 'unsigned long long'.
> >
> > I do not know if it is a compiler problem but this is the simple fix
> > (works on my systems):
> >   
> 
> Thanks very much for the patch.  We have a more general fix for this in
> Ingo's tip.git tree, but I overlooked that this particular problem
> affected current -rc.
> 
> Ingo, this is fixed by the phys_addr_t + PFN_PHYS() patches.  Should 
> we send them up to Linus, or do an ad-hoc fix in this one place?

send an ad-hoc fix please .. the phys_addr_t patches have a too wide 
impact i think.

	Ingo

[PATCH] xen: Fix for xen guest with mem > 3.7G

[Jeremy Fitzhardinge]

PFN_PHYS() can truncate large addresses unless its passed a suitable
large type.  This is fixed more generally in the patch series
introducing phys_addr_t, but we need a short-term fix to solve a
regression.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: roberto@unbit.it
---
 arch/x86/xen/setup.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

===================================================================
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -42,7 +42,7 @@
 
 	e820.nr_map = 0;
 
-	e820_add_region(0, PFN_PHYS(max_pfn), E820_RAM);
+	e820_add_region(0, PFN_PHYS((u64)max_pfn), E820_RAM);
 
 	/*
 	 * Even though this is normal, usable memory under Xen, reserve

Re: [PATCH] xen: Fix for xen guest with mem > 3.7G

[Ingo Molnar]

* Jeremy Fitzhardinge <jeremy@goop.org> wrote:

> PFN_PHYS() can truncate large addresses unless its passed a suitable
> large type.  This is fixed more generally in the patch series
> introducing phys_addr_t, but we need a short-term fix to solve a
> regression.
> 
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> Cc: roberto@unbit.it

applied to tip/x86/urgent (see below), thanks guys!

	Ingo

-------------->
>From 5670a43d710a12fcbbfaefd3991002768b488d82 Mon Sep 17 00:00:00 2001
From: Jeremy Fitzhardinge <jeremy@goop.org>
Date: Sun, 14 Sep 2008 07:42:23 -0700
Subject: [PATCH] xen: fix for xen guest with mem > 3.7G

PFN_PHYS() can truncate large addresses unless its passed a suitable
large type.  This is fixed more generally in the patch series
introducing phys_addr_t, but we need a short-term fix to solve a
Xen regression reported by Roberto De Ioris.

Reported-by: Roberto De Ioris <roberto@unbit.it>
Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
 arch/x86/xen/setup.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index b6acc3a..d679010 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -42,7 +42,7 @@ char * __init xen_memory_setup(void)
 
 	e820.nr_map = 0;
 
-	e820_add_region(0, PFN_PHYS(max_pfn), E820_RAM);
+	e820_add_region(0, PFN_PHYS((u64)max_pfn), E820_RAM);
 
 	/*
 	 * Even though this is normal, usable memory under Xen, reserve

Re: [PATCH] xen: Fix for xen guest with mem > 3.7G

[Roberto De Ioris]

On Sun, 2008-09-14 at 07:42 -0700, Jeremy Fitzhardinge wrote:
> PFN_PHYS() can truncate large addresses unless its passed a suitable
> large type.  This is fixed more generally in the patch series
> introducing phys_addr_t, but we need a short-term fix to solve a
> regression.
> 
> Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
> Cc: roberto@unbit.it
> ---
>  arch/x86/xen/setup.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> ===================================================================
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -42,7 +42,7 @@
>  
>  	e820.nr_map = 0;
>  
> -	e820_add_region(0, PFN_PHYS(max_pfn), E820_RAM);
> +	e820_add_region(0, PFN_PHYS((u64)max_pfn), E820_RAM);
>  
>  	/*
>  	 * Even though this is normal, usable memory under Xen, reserve


In this way you pass a 64bit integer to the function, but max_pfn in
origin is still 32bit.

max_pfn need to be 64bit to supporto more than 4GB

> 
> 
-- 
Roberto De Ioris
http://unbit.it
JID: roberto@jabber.unbit.it

Re: [PATCH] xen: Fix for xen guest with mem > 3.7G

[Jeremy Fitzhardinge]

Roberto De Ioris wrote:
> In this way you pass a 64bit integer to the function, but max_pfn in
> origin is still 32bit.
>
> max_pfn need to be 64bit to supporto more than 4GB
>   

No, a 32-bit pfn (page frame number) is sufficient for 2^44 bytes of
memory.  Does this patch work for you?

    J

Re: [PATCH] xen: Fix for xen guest with mem > 3.7G

[Roberto De Ioris]

On Sun, 2008-09-14 at 23:09 -0700, Jeremy Fitzhardinge wrote:
> Roberto De Ioris wrote:
> > In this way you pass a 64bit integer to the function, but max_pfn in
> > origin is still 32bit.
> >
> > max_pfn need to be 64bit to supporto more than 4GB
> >   
> 
> No, a 32-bit pfn (page frame number) is sufficient for 2^44 bytes of
> memory.  Does this patch work for you?
> 
>     J


Ops, you are right, pfn is not in bytes ;)

The patch works.

-- 
Roberto De Ioris
http://unbit.it
JID: roberto@jabber.unbit.it