>  * I have also chosen a physical memory limit of 128 MB.  The 4c is
>  * architecturally limited to 256 MB, but 128 MB is more than will
>  * fit on present hardware.
> [ ... ]
> #define MAXMEM  (128 * 1024 * 1024)     /* no more than 128 MB phys mem */
> 
> this comment is rather dated, and only specific to some of the
> sun4c's anyway.  shouldn't this MAXMEM be changed to something
> else now?   or preferably removed all together...?

Reading a bit further in pmap.c:

#define MAXMEM  (128 * 1024 * 1024)     /* no more than 128 MB phys mem */
[...]
#define BTSIZE  (MAXMEM / (1 << SUN4CM_PGSHIFT) / NPGBANK)
[...]
int     pmap_dtos[BTSIZE];              /* dense to sparse */
int     pmap_stod[BTSIZE];              /* sparse to dense */

Two arrays are created based on this MAXMEM value. Looking at how
large those arrays are, until the day someone complains about a
machine with more than 128M not working I am loathe to change it...

(Quick calculation before I go to sleep: 16K locked down now, 32K if I
change MAXMEM to 256M.)

Libkvm also knows about this size restriction, since it reads this
table.  There is an argument that these tables should be dynamically
sized at startup -- not sure about this yet.

The HWTOSW() and SWTOHW() tricks are also still done on the sun4; all
this should possibly be replaced by VM NONCONTIG code later.