All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Carl Jones <carl.jones@gmail.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: 2.6.27-rc1 >4096MB issue
Date: Mon, 04 Aug 2008 20:07:36 -0700	[thread overview]
Message-ID: <4897C3F8.6070704@goop.org> (raw)
In-Reply-To: <df5598920808041800o7a08d026re9daca653f527f40@mail.gmail.com>

Carl Jones wrote:
> On Sun, Aug 3, 2008 at 4:00 AM, Jeremy Fitzhardinge <jeremy@goop.org> wrote:
>   
>> Carl Jones wrote:
>>     
>>> http://radium.outervoid.net/~carl/boot.log
>>> http://radium.outervoid.net/~carl/xmlist.log ('xm list test1 --long'
>>> output, in case that is helpful)
>>>
>>>       
>> Thanks.  Does this fix it?
>>
>> iff -r 25bf2d9a2e4c arch/x86/xen/setup.c
>> --- a/arch/x86/xen/setup.c      Fri Aug 01 17:12:18 2008 -0700
>> +++ b/arch/x86/xen/setup.c      Sat Aug 02 09:00:02 2008 -0700
>> @@ -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
>>
>>
>>   J
>>
>>     
>
> Yep works nicely now. I tested up to 15GB or so with with that patch
> applied and CONFIG_XEN_MAX_DOMAIN_MEMORY=32 set:
>
> testing:~# cat /proc/meminfo
> MemTotal:     15769832 kB
>   

Excellent, thanks.  That's 32-bit?  (That's a pretty silly amount of 
memory to give to a 32-bit system, but it's nice to know it works.)

Could you try this patch instead to see if it works?  It's a more 
general fix.

Thanks,
    J


Subject: make PFN_PHYS explicitly return 64-bit result

PFN_PHYS, as its name suggests, turns a pfn into a physical address.
However, it is a macro which just operates on its argument without
modifying its type.  pfns are typed unsigned long, but an unsigned
long may not be long enough to hold a physical address (32-bit systems
with more than 32 bits of physcial address).  This means that the
resulting address could be truncated if it doesn't fit within an
unsigned long.  This isn't generally a problem because most users end
up using it for "low" memory, but there's no reason why PFN_PHYS
couldn't be used for any possible pfn.

Unfortunately there's no univerally recognized type for holding a full
physical address, so this patch makes it always return a u64 result.
In theory this could generate worse code, but in practice it will make
no difference:
- most users end up casting the result to a pointer or unsigned long,
  so on 32-bit systems the compiler should be able to eliminate the 64
  bit part of the expression.
- most users are in init code, which is neither size or performance
  critical

This patch also introduces PFN_LOW_PHYS which explicitly operates on
an unsigned long.  It is currently unused, but it could be used to
document the fact that the caller expects that the result will fit
into an unsigned long.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
---
 arch/m32r/mm/discontig.c   |    2 +-
 include/asm-x86/xen/page.h |    4 ++--
 include/linux/pfn.h        |    3 ++-
 3 files changed, 5 insertions(+), 4 deletions(-)

===================================================================
--- a/arch/m32r/mm/discontig.c
+++ b/arch/m32r/mm/discontig.c
@@ -112,7 +112,7 @@
 				initrd_start, INITRD_SIZE);
 		} else {
 			printk("initrd extends beyond end of memory "
-				"(0x%08lx > 0x%08lx)\ndisabling initrd\n",
+				"(0x%08lx > 0x%08llx)\ndisabling initrd\n",
 				INITRD_START + INITRD_SIZE,
 				PFN_PHYS(max_low_pfn));
 
===================================================================
--- a/include/asm-x86/xen/page.h
+++ b/include/asm-x86/xen/page.h
@@ -76,13 +76,13 @@
 static inline xmaddr_t phys_to_machine(xpaddr_t phys)
 {
 	unsigned offset = phys.paddr & ~PAGE_MASK;
-	return XMADDR(PFN_PHYS((u64)pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
+	return XMADDR(PFN_PHYS(pfn_to_mfn(PFN_DOWN(phys.paddr))) | offset);
 }
 
 static inline xpaddr_t machine_to_phys(xmaddr_t machine)
 {
 	unsigned offset = machine.maddr & ~PAGE_MASK;
-	return XPADDR(PFN_PHYS((u64)mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
+	return XPADDR(PFN_PHYS(mfn_to_pfn(PFN_DOWN(machine.maddr))) | offset);
 }
 
 /*
===================================================================
--- a/include/linux/pfn.h
+++ b/include/linux/pfn.h
@@ -4,6 +4,7 @@
 #define PFN_ALIGN(x)	(((unsigned long)(x) + (PAGE_SIZE - 1)) & PAGE_MASK)
 #define PFN_UP(x)	(((x) + PAGE_SIZE-1) >> PAGE_SHIFT)
 #define PFN_DOWN(x)	((x) >> PAGE_SHIFT)
-#define PFN_PHYS(x)	((x) << PAGE_SHIFT)
+#define PFN_PHYS(x)	((u64)(x) << PAGE_SHIFT)
+#define PFN_LOW_PHYS(x)	((unsigned long)(x) << PAGE_SHIFT)
 
 #endif

  reply	other threads:[~2008-08-05  3:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-01  3:25 2.6.27-rc1 >4096MB issue Carl Jones
2008-08-01  5:13 ` Jeremy Fitzhardinge
2008-08-02  5:22   ` Carl Jones
2008-08-02 16:00     ` Jeremy Fitzhardinge
2008-08-05  1:00       ` Carl Jones
2008-08-05  3:07         ` Jeremy Fitzhardinge [this message]
2008-08-05  4:14           ` Carl Jones
2008-08-05  7:09           ` Jan Beulich
2008-08-05 15:52             ` Jeremy Fitzhardinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4897C3F8.6070704@goop.org \
    --to=jeremy@goop.org \
    --cc=carl.jones@gmail.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.