Re: vkernel working

[Mehul Chadha <mehulc87@xxxxxxxxx>]

On Sun, Feb 1, 2009 at 10:52 PM, Matthew Dillon
<dillon@apollo.backplane.com> wrote:
>
> :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.

Thanks for explaining the complex paging part. So actually what we are
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.

>    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>
>

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