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

[Juli Mallett]

On Mon, Jun 7, 2010 at 23:13, C. Jayachandran <c.jayachandran at gmail.com> wrote:
> On Tue, Jun 8, 2010 at 9:43 AM, Juli Mallett <jmallett at freebsd.org> wrote:
>> 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.

OK.

> 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).

Yeah, but we have a disinterest in supporting n32 kernels in base
because it breaks assumptions in so many parts of the kernel, so I
think the most reasonable expectation for base is to support o32 and
n64, and to strongly prefer n64 for systems where it's more
appropriate.

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

There's nothing pmap_mapdev can do on an o32 kernel with 32-bit PTEs
for a physical address >2^36.  (There are rather a lot of those on
Octeon.)

Juli.