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. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
