Page fault handling in vpagetable area clarification

[Matthew Dillon]

:Hello Matt,
:
:in your Sep 2 mail announcing the start of vkernel development you claim that:
:
:"when a virtual process running under a virtual kernel takes a page fault, it 
:must chain through the virtual kernel and cannot short-cut directly to the 
:real kernel to handle the page fault"
:
:I'm missing something here. Reading the code, in case of a page fault, trap() 
:(the one in platform/pc32/i386/trap.c) calls trap_pfault() which calls 
:vm_fault() with the map contained in p->p_vmspace as an argument. vm_fault() 
:notices it's dealing with a VM_MAPTYPE_VPAGETABLE map and calls into 
:vm_fault_vpagetable() which walks the vpagetable in the vkernel's vmspace to 
:find out what to map and vm_fault() finishes up returning KERN_SUCCESS. This 
:gets propagated as 0 to trap() which then jumps to out:, allowing the vkernel 
:process to continue in the alternate vmspace. I don't see the vkernel being 
:involved (other than having set up the pagetable). Can you (or anyone else) 
:give me a hint?
:
:TIA,
:Aggelos

    In fact we are both right.  My original description was not quite
    complete.

    The real kernel does walk the virtual page table and can handle the
    page fault for those pages that exist in the virtual page table.

    However, just like the real kernel, the virtual kernel populates the
    virtual page table 'on demand', which means that often there will not
    be a page in the virtual page table for the real kernel to find.  When
    that occurs the real kernel simulates a page fault for the virtual
    kernel to handle.

    The virtual kernel does use the same heuristic as the real kernel to
    try to populate parts of the page table ahead of time, but it probably
    needs to be beefed up considerably for the virtual kernel to operate
    efficiently.

    Another issue is that the in order to simulate the 'M'odified bit in
    the virtual page table's page table entries, the real kernel must
    initially map the pages read-only, even if they are read-write, so it
    can take the fault and update the bit in the virtual page table.  This
    interaction is entirely between the VM space and the real kernel and
    does not require the fault to be fed through to the virtual kernel, but
    it does add additional overhead.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>