Re: vkernel working

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:hello all,
:                I am a newbie in the field of kernel. I have been
:trying to understand the working of vkernel reading into the source
:code and the documents, but i have not been able to understand certain
:concepts.
:
:1) My first doubt is that when we create a virtual RAM by mmaping a
:file which is not synced back to the disk, is the kernel ie the
:vkernel inside the virual RAM or is it only in a different address
:space given to it by the linker??? I mean is the code and data of
:vkernel copied into the virtual RAM and then executed from there?? If
:yes which function does tht job??

    No, the virtual kernel's ELF binary is loaded outside the virtual
    ram space.  Once loaded and running, any allocations made by the
    virtual kernel (via kmalloc) are mapped out using the virtual ram,
    as well as any pages allocated for virtualized user processes.

:2) secondly i have not been able to understand the complex paging part
:of vkernel, by giving the mapping as MAPTYPE_VPAGETABLE how does real
:kernel map the vkernel page directory and table to itself, does it
:change the CR3 register to page directory given by vkernel when its
:scheduling the vkernel or any of vkernel's processes??? pls if anyone
:can explain me how paging is handled in vkernel?? I have read the
:document titled 'A Peek at the DragonFly Virtual Kernel' I have
:understood the process management part but having problems
:understanding the MM part ie paging...
:
:pls if anyone can help me in clearing the above doubts , i have been
:trying for many days but still havnt got the hook of it...
:
:Regards,
:Mehul

    It is a big confusing.  Think of the memory object underlying the
    mmap(... VPAGETABLE) as having both physical and virtual abstractions.
    The physical abstraction is a linear offset within the backing store
    for the mmap()'d space (the file backing the space).  The NOSYNC is
    just an optimization. We are telling the system not to fsync() the
    memory file, for obvious reasons.  The virtual abstraction is any
    access made via the mmap() address space.

    When a page fault is taken within the mmap()'d space, the real kernel
    traverses a virtual page table via 'physical' offsets within the
    backing store.  The virtual page table supplies the virtual<->physical
    translation (where, again, 'physical' in this case really just means
    a linear offset in the backing store for the mapped space).

    The real kernel then maps that offset into the real page table at the
    virtual address, and we are done.  No manipulation of CR3 occurs,
    these mappings work kinda like doing mmap() calls to map individual
    addresses, except much more efficiently.

    The self-mapping allows the virtual kernel to access the virtual page
    tables via the mmap()'d space itself, instead of having to lseek/write
    the underlying file to access the virtual page table.  This works
    the same way the real kernel creates self-maps of the real page tables
    in order to be able to access them.  To be clear here, the virtual
    page table is stored IN the virtual memory space's backing store,
    not in some other memory store.

    The virtual page tables are NOT directly accessed by the real kernel's
    MMU.  The virtual page tables are traversed by the real kernel in
    software, and the final translation is then entered into the real
    page table.

    Each virtual user process in the virtual kernel has its own virtual
    page table and each virtual page table is backed by a real page table.
    When the virtual kernel transfers control to a virtualized user
    process the real kernel switches to the related real page table and
    transfers execution control to the virtualized user process.  When a
    fault or signal is taken the real kernel switches back to the virtual
    kernel's address space before returning control back to the
    virtual kernel.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>