Messages in this thread |  | | | Date | Thu, 18 Sep 2008 11:00:33 -0700 | | From | Jeremy Fitzhardinge <> | | Subject | Re: [PATCH] x86: x86_{phys,virt}_bits field also for i386 (v3) |
| |
Jan Beulich wrote: >>>> Ingo Molnar <mingo@elte.hu> 18.09.08 13:20 >>> >>>> >> * Ingo Molnar <mingo@elte.hu> wrote: >> >> >>> * Jan Beulich <jbeulich@novell.com> wrote: >>> >>> >>>> I'm really sorry for that, yet another merge oversight (not caught >>>> because only re-tested on x86-64). Here's a better one. >>>> >>> ah, i see, the delta below. Nasty. >>> >> the attached config fails in a similar way. >> > > Hmm, yes, other than in .27, -tip derives resource_size_t from phys_addr_t, > regardless of CONFIG_RESOURCES_64BIT (and the config you provided > is a non-PAE one). I have to question that change, which I'm sure is > responsible for this failure. If there's a good reason for this, then > phys_addr_valid() should use phys_addr_t as its parameter type (and > so should ioremap() & Co), and the pre-processor conditional should > then change to depend on CONFIG_PHYS_ADDR_T_64BIT. Since ioremap() > would need to change first, I'd have to withdraw the patch until that > gets sorted out.
I take it we're talking about this chunk:
-static inline int phys_addr_valid(unsigned long addr) +static inline int phys_addr_valid(resource_size_t addr) { - return addr < (1UL << boot_cpu_data.x86_phys_bits); +#ifdef CONFIG_RESOURCES_64BIT + return !(addr >> boot_cpu_data.x86_phys_bits); +#else + return 1; +#endif
Is x86_phys_bits defined to be the actual number of address lines poking out of the CPU package, or the number of address bits we can meaningfully put into a pte?
I would say the simplest thing to do here is be explicit:
if (sizeof(addr) == sizeof(u64)) return !(addr >> boot_cpu_data.x86_phys_bits); else return 1; That's not ideal, but I guess its good enough. I assume x86_phys_bits can never be less than 32?
J
|  |