> The system page table must be in _physical_contiguous_ memory.

Check.

> The user page table must be in kernel virtual contiguous memory

Not for the KA620; the KA620 puts P0 and P1 ("user") page tables in
physical memory, not system virtual memory.  (Of course, how much
anyone not doing highly-custom embedded systems cares about the KA620
is another story.)

> This means that the user page table must have space allocated in the
> system page table before memory management is turned on.

Not quite.  All you need to do is allocate physically contiguous memory
later and you can move the system page tables around after boot.  (That
may be difficult to do under the assumptions NetBSD's MI code currently
makes; that's a different issue.)

Also, there's no reason in principle that the system page table can't
have holes - invalid PTEs (or perhaps they have to be valid but
no-access) each representing 64K of nonexistent/invalid userland space.
(Not that that helps reduce the system virtual address space demands of
the system page table, though, just the physical memory demands in that
you need not store a physical page full of invalid user PTEs.  And
system virtual space still means physical space to store system PTEs,
which is where the problem started.)

> If you can find a way to get around this, you'll be a hero.  Noone
> else has been able to do it for 25 years :-)

Oh, it's easy enough to get around.  Just not easy to get around with
resonable efficiency.  (Just set up the user PTEs in segments, one for
each contiguous or near-enough-to-contiguous chunk of user VM.  Set
P0LR/P0BR to map just one segment.  Switch them to another segment on a
page fault.  Hm, I'm not sure that _would_ work; it's possible for a
single simple instruction to require access to at least three or four
pages, arbitrarily widely scattered in VM; unless they're all mapped
_simultaneously_ (if the instruction is simple enough), the instruction
will never complete.)

> Why cannot this be solved as it was in the 3BSD VM system then, by
> letting a process allocate more pte space when it grows?  Because of
> the way sbrk/mmap interacts; all mmap'ed memory is above MAXDSIZ

(and must be, in case sbrk grows the data segment lots)

> and therefore all space between the break and MAXDSIZ must have at
> least system pte's associated with it.

Thought: move _start up.  Put it at 0x80000000-MAXDSIZE.  Put the stack
just below _start.  Put mmap()ed memory in P0 space, starting at 0 (or
whatever small address, if you want to leave 0 unmapped).  That won't
help; you'd still need system virtual space for PTEs for that MAXDSIZE
user virtual space - but it leads to...

Another idea: I notice that the max stack size is a good deal smaller
than the max data size.  How about this?  (Let MAXSSIZE be the max
stack size.)

P0 space holds stack, starting at MAXSSIZE (plus a little, if you want
0 unmapped) and growing towards 0.  Text starts at MAXSSIZE with data
and bss just above that (as now, with respect to the relative positions
of text/data/bss).  sbrk() space grows up above bss.  mmap()ed segments
go in P1 space, starting (of course) at the top and growing down.

Then the only space you have to permanently allocate anything to back
even if userland never uses it is the stack, which is a lot smaller
than present MAXDSIZE, never mind what you might want to increase
MAXDSIZE to.

Unless you want to increase the maximum stack space to large values
too.  Which might be nice, but given the hardware we're stuck with....

Of course, that juggle may come at a higher price than removing sbrk.
That's a judgement call for you people to make.  I just point out
possibilities. :-)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B