L4 fpages

[Björn Döbel]

Hi,

> OK, but what if I want extend address space of a task
> how I can do this? And also, what is the default size
> for a address space for a task?

you need to distinguish two things here. Part one are the concepts 
behind memory management, part two are the concrete implementations in 
Fiasco.OC and the L4 runtime environment.

Let's start with the concepts.

When an application runs (e.g., because you just started it and it is 
now trying to access its first instruction), it accesses memory. If 
there is now mapping in the hardware page table, a page fault exception 
is raised by the CPU. This ends up being handled by the kernel.

We do user-level memory management, which means that everything from 
page fault handling to higher level concepts is done by applications 
themselves instead of the kernel. Therefore, the kernel redirects the 
page fault to a user-level page fault handler. The handler is just 
another user-level thread, which then performs the real work of handling 
a page fault, e.g., by mapping an already available range of memory 
(e.g., a part of a file) to the faulting thread.

To do so, the handler needs to keep knowledge about how a client's  
address space.


Now to the implementation:

* The Fiasco.OC kernel knows a page fault handler thread for each thread 
in the system.
* The kernel uses IPC for sending the page fault message to the handler.
* The handler can map an arbitrary part from his own address space to 
the client. We call such a part a "region".
* Mapping regions is done through IPC. To do so, the sender attaches a 
special data type describing a memory region to the
    IPC message. The kernel detects this and establishes a memory 
mapping accordingly. This data type is called a "flexpage".
* In order to maintain a task's address space layout, every task has a 
dedicated "region manager" thread. This thread acts as
    the PF handler for all other threads in a task and maintains a 
consistent view of the address space.
* In order to be able to construct the address space from regions of 
different sources (e.g., the application binary coming from
    a file system and anonymous memory coming from a memory manager), we 
introduce another abstraction for describing
    memory regions, called "data spaces".


This is the very short overview of memory management. More details can 
for instance be found in our lecture on microkernel-based operating 
systems, which's slides are available from 
http://www.inf.tu-dresden.de/index.php?node_id=1314

Cheers,
Bjoern