> Does NetBSD already support phyical memory > max process virtual
> address space on non-x86 hardware, like the Sun hardware Eduardo
> mentioned, where the kernel can't map all of physical memory (or was
> that a Solaris kernel?)

Yes, once again on Sun hardware.  In fact that's the reason I needed
to separate vm_offset_t into vaddr_t and paddr_t.  UltraSPARC machines
have 44 bit physical addresses, and although RAM starts at physical
address zero and goes up, devices are usually mapped well above the
32-bit limit, mostly around 0x1ff.0000.0000.

To support > 32 bit physical memory you need to:

	make paddr_t large enough to encode a full physical address 
	(> 32 bits)

	fix any assumptions pmap has about being able to map all of
	RAM

	make whatever changes are needed to the pmap layer to store
	the proper number of bits in the page tables/hash tables/etc.

	limit the size of the buffer cache

	tweak the startup code to make sure you don't run out of
	kernel virtual address space just trying to map in the
	structures needed to keep track of all the pages of RAM

The rest is bugfixing.

Some architectures have hardware restrictions that prevent you from
doing this, but on those you couldn't build a machine that has more
than a certain amount of physical memory.

=========================================================================
Eduardo Horvath				eeh@netbsd.org
	"I need to find a pithy new quote." -- me