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