Re: Question regarding x86_64 __PHYSICAL_MASK_SHIFT
From: Tejun Heo
Date: Tue Oct 04 2005 - 14:19:36 EST
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/