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