DragonFly BSD
DragonFly kernel List (threaded) for 2006-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

HEAD may destabilize in the near term

From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 12 Sep 2006 15:23:13 -0700 (PDT)

    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.

 * sysctl vm.vkernel_enable=1 
 * BASIC TEST PROGRAM - note: page table scheme will change in the near
 * future.

#include <sys/types.h>
#include <sys/mman.h>
#include <sys/vkernel.h>

main(int ac, char **av)
    char *ptr;
    vpte_t *level1;
    vpte_t *level2;

    ptr = mmap(NULL, 32*1024*1024, PROT_READ|PROT_WRITE, 
                MAP_SHARED|MAP_ANON|MAP_VPAGETABLE, -1, 0);
    printf("ptr %p\n", ptr);

     * Create a two-level page table. 
    level1 = (void *)ptr;
    level1[0] = VPTE_PS;        /* linear map first 4MB */
    level1[1] = 4096;           /* two-level page table for 2nd 4MB */

    level2 = (void *)(ptr + PAGE_SIZE);
    level2[0] = (4096*1024);
    level2[1] = (4096*1024);
/*    level2[2] = VPTE_IV;*/	/* uncomment to cause 4MB block to segfault */
				/* else it's an alias of the first block */
    ptr[4096*1024] = 23;
    printf("test alias %d (should be 23)\n", ptr[4096*1024+4096*0]);
    printf("test alias %d (should be 23)\n", ptr[4096*1024+4096*1]);
    printf("test alias %d (should be VPTE_PS == 2)\n", ptr[4096*1024+4096*2]);
    /* printf("seg fault\n"); */
    /* printf("test alias %d (should be VPTE_PS == 2)\n", ptr[4096*1024+4096*2]); */

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]