Re: Question regarding x86_64 __PHYSICAL_MASK_SHIFT

[Tejun Heo <htejun@gmail.com>]

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