I new to the L4 microkernel and do not understand how fpages works. What are the functions of fpages? Can them be used to extend the address space? Are they just for copy a region from one address space to other address space?
Hi,
On Fri Jan 14, 2011 at 09:18:45 -0800, jason philip wrote:
I new to the L4 microkernel and do not understand how fpages works. What are the functions of fpages? Can them be used to extend the address space? Are they just for copy a region from one address space to other address space?
A flexpage is a datatype that describes a piece in some space, compactified in just a single machine word (i.e. 4 or 8 bytes). It consists of an position in there, a size and some other bits. Yes, that's abstract. For example a flexpage for memory describes a memory region. It consists of an address with the granularity of pages, a size specifying the number of pages (usually in log2 size) and some rights bits. Now when mapping memory around a flexpage describes which memory to map and where to put it. Flexpages are also used for capabilities and I/O ports.
Adam
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?
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
On 15.01.2011 19:15, Björn Döbel wrote:
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
The L4Re docs at http://os.inf.tu-dresden.de/L4Re/doc/ might also be a good starting point.
Bjoern
On 16.01.2011 03:08, Jason Philip wrote:
one more thing, what io-fpages are and what are them used for?
As I explained yesterday, flexpages (== fpages) are the internal data type that is used to describe regions of memory when establishing a mapping between two address spaces.
This was not the whole truth. As Adam already said, flexpages are not only used for memory mappings, but also for mapping other kinds of resources, such as capabilities (= the right to talk to a kernel object) and I/O ports. The latter is what io-fpages are for.
Bjoern
l4-hackers@os.inf.tu-dresden.de