From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: 2.6.27-rc1 >4096MB issue Date: Tue, 05 Aug 2008 08:52:05 -0700 Message-ID: <48987725.8060006@goop.org> References: <48929B85.9030004@goop.org> <489484B6.7000003@goop.org> <4897C3F8.6070704@goop.org> <489818C5.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <489818C5.76E4.0078.0@novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: Carl Jones , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org Jan Beulich wrote: >>>> Jeremy Fitzhardinge 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