DragonFly kernel List (threaded) for 2007-02
Re: Page fault handling in vpagetable area clarification
: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?
In fact we are both right. My original description was not quite
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
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.