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

--

[ message continues ]

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,

--

[ message continues ]

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

	Ingo
--

[ message continues ]

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


--

[ message continues ]

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

[ message continues ]

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

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

--

[ message continues ]

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

    J
--

[ message continues ]

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

The patch works.

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

--

[ message continues ]