Messages in this thread | | | Date | Fri, 18 Jun 2010 09:32:37 +0900 | From | Kenji Kaneshige <> | Subject | Re: [PATCH 1/2] x86: ioremap: fix wrong physical address handling |
| |
(2010/06/17 22:46), H. Peter Anvin wrote: > On 06/17/2010 02:35 AM, Jeremy Fitzhardinge wrote: >>>> >>>> By the way, is there linux kernel limit regarding above 44-bits physical >>>> address in x86_32 PAE? For example, pfn above 32-bits is not supported? >> >> That's an awkward situation. I would tend to suggest that you not >> support this type of machine with a 32-bit kernel. Is it a sparse >> memory system, or is there a device mapped in that range? >> >> I guess it would be possible to special-case ioremap to allow the >> creation of such mappings, but I don't know what kind of system-wide >> fallout would happen as a result. The consequences of something trying >> to extract a pfn from one of those ptes would be >> >>> There are probably places at which PFNs are held in 32-bit numbers, >>> although it would be good to track them down if it isn't too expensive >>> to fix them (i.e. doesn't affect generic code.) >>> >> >> There are many places which hold pfns in 32 bit variables on 32 bit >> systems; the standard type for pfns is "unsigned long", pretty much >> everywhere in the kernel. It might be worth defining a pfn_t and >> converting usage over to that, but it would be a pervasive change. >> > > I think you're right, and just making 2^44 work correctly would be good > enough. Doing special forwarding of all 52 bits of the real physical > address in the paravirt case (where it is self-contained and doesn't > spill into the rest of the kernel) would probably be a good thing, though. > > -hpa >
I'll focus on making 2^44 work correctly. Then, I'll do the following change in the next version of my patch.
- The v.2 patch uses resource_size_t for pfn. I'll keep using resource_size_t for pfn also in v.3, because there is no reason to leave it being "unsigned long".
- Use PHYSICAL_PAGE_MASK for masking physical address as v.1 patch did. I think changing the definition of PAGE_MASK is a little risky.
Thanks, Kenji Kaneshige
| |