doubts in vkernel

[Matthew Dillon]

:Firstly,
:
:Since the vkernel code and static data are not part of the Virtual RAM , so
:how are the virtual to physical mapping done in this case, I mean while
:initialization it executes the code from outside the V RAM , which is fine,
:but after starting of user process and then context switching into the
:vkernel again, how is control passed to code and data outside the mmap'ed
:backing store or V RAM

    The virtual kernel's address space from the point of view of the real
    kernel is just a normal ELF address space.  The virtual kernel does
    a special mmap() call to associate a portion of that address space 
    with a virtual page table (the vkernel's own virtual page table).

    So when the vkernel is running in its own address space it has access
    to text, data, bss, and this special mmap()'d virtually-paged subspace.

    This subspace is backed by the physical memory file.

    This virtually paged subspace is what the vkernel uses to share pages
    between its own address space and the address spaces of the 
    virtual user processes it runs.

:Secondly,
:
:In case of page faults the way i understand the architecture is that when a
:fault is taken it is an exception so it is directly transferred to the real
:kernel, which knows that this fault is of the vproc, so it reads the virtual
:...
:So we have 2 scenarios in page faults, can anyone pls explain me with a
:practical eg. how 2 scenarios come into picture.

    The real kernel will take the fault whether it comes from a virtual
    user process context or the virtual kernel context itself.  The real
    kernel will then attempt to resolve the page fault.  If the page fault
    occucs within a mmap'd virtual page table the real kernel will walk
    the virtual page table to locate the proper translation, then load it
    into the real pmap and return, resuming execution of the context.

    If the real kernel is not able to satisfy the page fault... for example,
    if when it walks the virtual page table it finds an invalid virtual
    PTE, then it takes the following actions:

    (I) If the context was a virtual user process

	* The real kernel will switch back to the vkernel context.

	* The real kernel will 'return' from the system call the
	  vkernel had made to it to run the virtual user process
	  context in th first place.

	* As part of that the real kernel stores the trap frame so the
	  vkernel can determine what kind of exception the virtual user
	  process took, and act on it.

	  The vkernel will then resolve the issue and loop up, making the
	  system call to transfer control back to the virtual user process
	  context.

    (II) If the context was the virtual kernel itself trying to access 
	 an area within the virtual page table submap that it mmap()ed

	* The real kernel generates a SIGSEGV signal to the virtual kernel

	* The virtual kernel takes it as a normal signal handler

	* The virtual kernel examines the ucontext the real kernel supplied
	  to the signal handler and resolves the fault.

	* The virtual kernel returns from the signal handler, causing the
	  real kernel to resume the original vkernel context and retry
	  the instruction.

:I have also not understood the use of system call vmspace_mmap(), I mean if
:the real kernel maintains a simple structure of vproc with a single entry of
:vm_map_entry with address from 0 to VM_MAX_USER_ADDRESS then how does the
:vmspace_mmap help.
:
:Regards,
:Abhinav

    The vmspace_mmap() is used in two situations.  First the vkernel must
    construct a vmspace context for the virtual user process that it wants
    to run.  It constructs this context using vmspace_mmap().  The entire
    memory map for the virtual user process's vmspace is a VPAGETABLE mmap.

    Second, the vkernel must construct its 'kernel virtual memory' area.
    It does this by creating a VPAGETABLE mmap() within its own address
    space.  This mmap() uses the same backing store as the VPAGETABLE mmap
    the virtual kernel makes in the virtual user process vmspace contexts,
    allowing it to share physical memory between itself and all of its
    virtual user processes.

    Each vmspace context, as well as the virtual kernel's own context,
    supplies its own virtual page directory base offset for the
    VPAGETABLE mmapping.  The virtual kernel manages the virtual page 
    tables for all the virtual user processes as well as for its own
    kernel virtual memory and supplies the correct virtual page directory
    base offset for each context.

    Thus in its own address space it sees its own kernel virtual memory,
    but in any given virtual user process vmspace only the virtual user
    process's memory map is visible to the running virtual user process
    (just like a real kernel manages multiple page tables, one for itself
    and one for each real user process under management).

    All of these page tables reside in the 'ram' backing store for the
    virtual kernel, along with all the rest of the virtual kernel's 'ram'.
    The virtual kernel's ELF image, static DATA, and BSS, are outside
    of this 'ram'.   The vkernel creates this 'ram' file based on the
    memory size you tell it with -m, e.g. '-m 128m'.  It's actually a
    memory-mapped file but one that is accessed through the special
    virtual page table mechanism via VPAGETABLE mmap()'s.

						-Matt