To quote Matthew Dillon:

While I hope to avoid any destabilization, I am fiddling with some pretty hairy code in the VM system so this is a head’s up! I have successfully implemented a basic MAP_VPAGETABLE feature that
allows a mmap()’d section of memory to be governed by a virtual page
table. Basically the backing store for the mmap()’d space is the
‘physical memory’ used to map the space, and the mapping of the space
is then governed by a ‘page table’ stored in that physical memory.
(It is only physical memory from the point of view of the virtual
kernel, not the real kernel of course). The mapping will store a
physical page directory offset to tell the VM system where the page
table is.

I will be fleshing the scheme out in coming days. My TODO list:

* Add a system call to allow the ‘page directory’ page to be set
(right now it’s 0). For obvious reasons.

* Add a system call to invalid the real kernel’s PMAP so virtual
page table entries can be updated and made visible to the program.

* Redo the page table scheme to make it generic across 32 and 64 bit
architectures, and to allow more then 4GB of ‘memory’. The backing
store for the mapping is the ‘memory’ for the virtual kernel and
there is certainly no reason why we would have to limit it to 4GB.

This basic feature is necessary to support virtual kernels running in
userland. The virtual kernel will use the MAP_VPAGETABLE feature to
manage its own virtual space, including giving it the ability to alias
pages between it and vmspace contexts representing user processes under
its control. User processes under the virtual kernel’s control will
also use an internal version of MAP_VPAGETABLE to control their
ENTIRE vmspace’s, with the same backing store as the virtual kernel’s
managed space, allowing the virtual kernel to control mappings in
those vmspace’s on a page-by-page basis.

In otherwords, the abstraction will allow a virtual kernel to manage
VM spaces just like the real kernel does. Pretty spiffy if I do say
so myself.

Awesome guy!!