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/
Home Products Support Community News


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

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


Xen-devel mailing list

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