DragonFly kernel List (threaded) for 2009-02
Re: vkernel working
: 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
: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...
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
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