Subject: vm layout changes
To: None <port-arm32@netbsd.org>
From: Chris Gilbert <chris@paradox.demon.co.uk>
List: port-arm32
Date: 08/09/2001 11:10:36
Hi,

Just to forewarn people at some point in the near future (month or so)  I'm 
planning to rearrange the VM space again, long term this should stop us 
having the issues of running out of kvm space as happened on the RiscPC at 
the begining of the year.

The current layout is:
 * PDE#s        VA range                usage
 * 0->3835      0x0 -> 0xefc00000       user address space
 * 3836->3839   0xefc00000->            recursive mapping of PDP (used for
 *                      0xf0000000      linear mapping of PTPs)
 * 3840->3851   0xf0000000->            kernel text address space (constant
 *                      0xf0c00000      across all pmap's/processes)
 * 3852->3855   0xf0c00000->            "alternate" recursive PDP mapping
 *                      0xf1000000      (for other pmaps)
 * 3856->4095   0xf1000000->            KVM and device mappings, constant
 *                      0x00000000      across all pmaps


(note that not all of the above is guarenteed to be accurate, the bits on the 
PDP's maybe wrong)

My plan is to lay it out like:

0x0 -> 0xbfc00000	User address space
0xbfc00000 -> 0xc0000000  PDP space
0xc0000000 -> 0xf0000000  KVM space (controlled by pmap_growkernel function)
0xf0000000 -> 0xf0c00000  kernel text address space
0xf0c00000 -> 0xf1000000  alternate PDP mapping
0xf1000000 -> 0x00000000  VM space for device mapping, arch dependant.

The reason for keeping the kernel where it is, is there's no real need to 
move it and because we know that the bootloaders work with it there, and some 
of the bootloaders are no longer maintained.

The benefit of this is that we gain the potential to have 768MB of KVM space 
(should be more than enough :)  We also then have the KVM starting at the 
same address and ending at 0xf0000000, unlike currently where the end of kvm 
varies depending on what device mappings there are, and what setting is in 
vmparam.h  Currently the smallest one is shark with 64MB of KVM, prior to 
recent changes on riscpc it had the smallest kvm with 48MB which was too 
small for the new features in -current.

It should also help with having shared arm32 lkm's, rather than potentially 
needing a recompile on each arch.  (note that I don't use lkm's so I don't 
know if this is currently needed or not)

My main concern with this is the reduction in available user space from near 
4GB to only 3 GB :)  I'm also not sure where the linker links shared libs in, 
and if these changes will effect that.

Order to do all this is:
finish meddling^Wworking on the pmap
implement pmap_growkernel
shift the vm addresses around.

Suggestions? objections?  Is this a mad idea?   Am I missing something (well 
I probably am I'm a developer ;)

This is probably a couple of months away.

Chris