Messages in this thread | | | Date | Wed, 05 Oct 2005 04:19:01 +0900 | From | Tejun Heo <> | Subject | Re: Question regarding x86_64 __PHYSICAL_MASK_SHIFT |
| |
Andi Kleen wrote: > On Tuesday 04 October 2005 20:52, Tejun Heo wrote: > >> Hello, Andi. >> >>On Tue, Oct 04, 2005 at 07:24:56PM +0200, Andi Kleen wrote: >> >>>You're right - PHYSICAL_MASK shouldn't be applied to PFNs, only to full >>>addresses. Fixed with appended patch. >>> >>>The 46bits limit is because half of the 48bit virtual space >>>is used for user space and the other 47 bit half is divided into >>>direct mapping and other mappings (ioremap, vmalloc etc.). All >>>physical memory has to fit into the direct mapping, so you >>>end with a 46 bit limit. >> >> __PHYSICAL_MASK is only used to mask out non-pfn bits from page table >>entries. I don't really see how it's related to virtual space >>construction. > > > Any other bits are not needed and should be pte_bad()ed. > > Ok there could be IO mappings beyond 46bits in theory, but I will worry about > these when they happen. For now it's better to error out to easier detect > memory corruptions in page tables (some x86-64 CPUs tend to machine > check when presented with unmapped physical addresses, which > is nasty to track down) >
Ahh.. I see.
> >>>See also Documentation/x86-64/mm.txt >> >> Thanks. :-) >> >> I think PHYSICAL_PAGE_MASK and PTE_FILE_MAX_BITS should also be >>updated. How about the following patch? Compile & boot tested. > > > No, I think the existing code with my patch is fine.
Hmmm.. but, currently
* PHYSICAL_PAGE_MASK == (~(PAGE_SIZE-1)&(__PHYSICAL_MASK << PAGE_SHIFT) == (0xffffffff_fffff000 & (0x00003fff_ffffffff << 12) == 0x03ffffff_fffff000 while it actually should be 0x00003fff_fffff000
* PTE_FILE_MAX_BITS == __PHYSICAL_MASK_SHIFT == 46, but only 40bits are available in page table entries.
-- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |