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
-
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/