svn commit: r208589 - head/sys/mips/mips

[C. Jayachandran]

On Tue, Jun 8, 2010 at 9:43 AM, Juli Mallett <jmallett at freebsd.org> wrote:
> Hey JC,
>
> On Mon, Jun 7, 2010 at 21:07, C. Jayachandran <c.jayachandran at gmail.com> wrote:
>> Yes. I saw the PAE top level page table code and thought I could use
>> that mechanism for allocating MIPS page table pages in the direct
>> mapped memory. The other reference I used was
>> pmap_alloc_zeroed_contig_pages() function in sun4v/sun4v/pmap.c which
>> uses the vm_phys_alloc_contig() and VM_WAIT.  I had also thought of
>> using the VM_FREEPOOL_DIRECT which seemed to be for a similar purpose,
>> but could find see any usage in the kernel.
>
> Do you intend to support o32 kernels in your port indefinitely?  I
> wonder whether this work is just stopgap until the systems which have
> large amounts of RAM can just use n64 kernels.

I think the page table work will be needed for o32 and n32, and I
would like to support one of them as the preferred 32bit mode for our
port.

BTW, n32 with >4GB RAM can be supported with XKPHYS for page table
entries. The options there would be either special allocator for the
segtab (11+9+12 addr space split), or to use special allocator for all
the page table pages (10+10+12 split).

> At least on Octeon it
> seems to me that n64-only is the right answer if at all possible,
> since there are really a lot of parts of the kernel that just can't
> reasonably work otherwise (use of rman_get_virtual with io ports, for
> instance.)

Not sure I understand this part - I thought pmap_mapdev() would handle
these - but I may be mistaken.

JC.