[PATCH] Move from kseg0 to xkphys for 64 bit.

[Neel Natu]

Hi JC,

I have a few comments below.

Index: sys/mips/include/cpuregs.h
===================================================================

+#define	MIPS_XKPHYS_LARGEST_PHYS	0x10000000000
+#define	MIPS_XKPHYS_MASK		0x0ffffffffff

Perhaps add a comment that this limit is less than that allowed by the
architecture because we can only address 40 bits with our 3 levels of
page tables.

Don't these macros need a 'ULL' type qualifier as well?

Index: sys/mips/mips/pmap.c
===================================================================

Do you need to maintain 'valid1' in 'local_sysmap' anymore? It seems we
only check 'valid2' in pmap_lmem_unmap().

 static __inline pd_entry_t *
 pmap_pdpe_to_pde(pd_entry_t *pdpe, vm_offset_t va)
 {
+
 	return pdpe;
 }

 static __inline
 pd_entry_t *pmap_pde(pmap_t pmap, vm_offset_t va)
 {
+
 	return pmap_segmap(pmap, va);
 }

Parentheses around the return value.

@@ -1032,7 +1080,11 @@
 pmap_grow_pte_page_cache()
 {

+#ifdef __mips_n64
+	vm_contig_grow_cache(3, 0, 0xffffffffffUL);
+#else
 	vm_contig_grow_cache(3, 0, MIPS_KSEG0_LARGEST_PHYS);
+#endif
 }

Why not use MIPS_XPHYS_LARGEST_PHYS in the __mips_n64 case instead of using
a literal value?

best
Neel

On Mon, Aug 16, 2010 at 9:10 AM, Jayachandran C.
<c.jayachandran at gmail.com> wrote:
> I've attached the changes to move the 64bit port to use 64bit XKPHYS
> mapping of the physical memory instead of the current KSEG0.  With
> this changes the 64bit port will use just one freelist, and can
> allocate page table pages from anywhere in the memory.
>
> The changes are mainly to introduce macros like
> MIPS_PHYS_TO_DIRECT(pa), MIPS_DIRECT_TO_PHYS(), which will use KSEG0
> in 32 bit compilation and XKPHYS in 64 bit compilation. I also ended
> up changing the macro based PMAP_LMEM_MAP1(), PMAP_LMEM_MAP2(),
> PMAP_LMEM_UNMAP() to inline functions.
>
> I have also introduced a macro MIPS_DIRECT_MAPPABLE(pa), which will
> further reduce the cases in which we will need to have a special case
> for 64 bit compilation.
>
> Please let me know your comments.
>
> Thanks,
> JC.
>