Messages in this thread | | | Date | Thu, 17 Jun 2010 15:21:09 +0900 | From | Kenji Kaneshige <> | Subject | Re: [PATCH 1/2] x86: ioremap: fix wrong physical address handling |
| |
(2010/06/17 15:03), H. Peter Anvin wrote: > On 06/16/2010 09:55 PM, Kenji Kaneshige wrote: >>> >>> I think they might be. Kenji? >> >> No. My addresses are in the 44-bits range (around fc000000000). So it is >> not required for my problem. This change assumes that phys_addr can be >> above 44-bits (up to 52-bits (and higher in the future?)). >> >> 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? >> > > 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.) > > This also affects paravirt systems, i.e. right now Xen has to locate all > 32-bit guests below 64 GB, which limits its usefulness. > >> #ifdef CONFIG_X86_PAE >> /* 44=32+12, the limit we can fit into an unsigned long pfn */ >> #define __PHYSICAL_MASK_SHIFT 44 >> #define __VIRTUAL_MASK_SHIFT 32 >> >> If there is 44-bits physical address limit, I think it's better to use >> PHYSICAL_PAGE_MASK for masking physical address, instead of "(phys_addr >>>> PAGE_SHIFT)<< PAGE_SHIFT)". The PHYSICAL_PAGE_MASK would become >> greater value when 44-bits physical address limit is eliminated. And >> maybe we need to change phys_addr_valid() returns error if physical >> address is above (1<< __PHYSICAL_MASK_SHIFT)? > > The real question is how much we can fix without an unreasonable cost. >
Thank you very much. I understand the situation.
Thanks, Kenji Kaneshige
| |