Awesome work, Matt!
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_VPAGETABLEfeature 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_VPAGETABLEfeature 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 ofMAP_VPAGETABLEto 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!!