WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] 2.6.27-rc1 >4096MB issue

Jan Beulich wrote:
Jeremy Fitzhardinge <jeremy@xxxxxxxx> 05.08.08 05:07 >>>
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.

Couldn't you use resource_size_t here?

Yeah, looks like I can. It had crossed my mind, but I'd vaguely remembered that it might no be set if you don't have 64-bit IO devices. But it looks like it's set for all interesting cases (64 bit machines, and 32-bit x86 PAE).

   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>