vkernel working
Matthew Dillon
dillon at apollo.backplane.com
Tue Feb 3 14:29:26 PST 2009
:doing in vkernel is shadowing of pages ie mapping the virtual page
:tables in vkernel to real page tables in real kernel , so does that
:mean we change the CR3 register to the real page tables on every
:context switch within the vkernel else how will a virtual address lets
:say 100 in vproc 1 and similarily in vproc 2 be differentiated with
:respect to its map on the physical memory.
Yes, any context switch reloads the CR3 register, including context
switches between the vkernel and virtualized user process (and back
again).
:Secondly is kernelPTA the variable which points the offset into the
:virtual RAM???
:
:As you had expalined about the page faults where in the real kernel
:traverses the virtual page table and then makes an appropriate entry
:into its page tables, but lets say tht vkernel forks a process then
:vkernel makes appropriate entries in its own virtual page tables so at
:tht time does it also makes a system call to make similar entries into
:the real page tables??
:
:Regards,
:Mehul
The virtual kernel has its own page table. KernelPTD points to the
self-map of the page directory for this page table, KernelPTA points
the base of the page tables mapped by KernelPTD. The page tables are
mapped linearly to make lookups easier.
When the virtual kernel makes modifications to its virtual page table
it informs the real system of the modifications via the mcontrol()
system call. This is a new system call added to DragonFly which is
an expanded version of madvise().
-Matt
Matthew Dillon
<dillon at backplane.com>
More information about the Kernel
mailing list