Question about memory management in L4 Fiasco O.C + L4re

Mahdi Aichouch foxmehdi at gmail.com
Mon Dec 14 16:47:11 CET 2015


Hello Adam,

Is it possible to combine the flags such as "pinned_segs" and "eager_map"
of the loader to create fixed memory region for the text and data segments
of an L4 task. As for example :

L4.default_loader:start( { { ldr_flags = L4.Ldr_flags.eager_map,
L4.Ldr_flags.pinned_segs }, log = { "hello1", "green" } }, "rom/hello");

What I am trying to do is to find a way to know where each segment (text,
data, heap and stack) of an L4 task is loaded into physical memory, that
is, for each segment I need to determine its start and end addresses in
physical memory.

Thank you very much for your answer.

Best regards,

Mahdi





On Fri, Dec 11, 2015 at 4:49 PM, Mahdi Aichouch <foxmehdi at gmail.com> wrote:

> Hello Adam,
>
> I tried to find where the code, data and stack segments of L4 tasks are
> loaded into physical memory by moe.
> I instrumented the code of "pkg/libloader/include/elf" and
> "pkg/l4re_kernel/server/src/loader.c" programs by using the "phys( )"
> method of Dataspace object in order to know the physical addresses, as
> shown in the code snippet below.
>
> I tested the hello example, by running 4 instances of the hello program.
> The problem is that I was unable to get the physical addresses, all the
> addresses seem to be virtual, as shown in the logs below.
>
> Could you please tell me what is wrong in my investigation, what is the
> right way to obtain the physical memory addresses of an L4 user programs.
>
> Thank you very much in advance.
>
> Best regards,
> Mahdi
>
>
>
>
> Phdr_load(l4_addr_t base, Const_dataspace bin, App_model *mm,
>             unsigned r_flags, Dbg const &dbg)
>   : base(base), r_flags(r_flags), bin(bin), mm(mm), dbg(dbg)
>   {}
>
>   void operator () (Elf_phdr const &ph) const
>   {
>     using L4Re::chksys;
>
>     if (ph.type() != PT_LOAD)
>       return;
>
>     if (!ph.memsz())
>       return;
>
>     char *paddr = (char*)(l4_trunc_page(ph.paddr()) + base);
>     l4_umword_t offs = l4_trunc_page(ph.offset());
>     l4_umword_t page_offs = ph.offset() & (L4_PAGESIZE-1);
>     l4_umword_t fsz  = ph.filesz();
>     if (fsz && page_offs != (ph.paddr() & (L4_PAGESIZE-1)))
>       {
>         dbg.printf("malformed ELF file, file offset and paddr mismatch\n");
>         chksys(-L4_EINVAL, "malformed elf file");
>       }
>
>     l4_umword_t size = l4_round_page(ph.memsz() + page_offs);
>
> l4_addr_t phys_offset = 0;
> l4_addr_t phys_addr;
> l4_size_t phys_size;
>
>     if ((ph.flags() & PF_W) || ph.memsz() > fsz || mm->all_segs_cow())
>       {
>         // copy section
>         Dataspace mem = mm->alloc_ds(size);
>         mem->phys(offs, phys_addr, phys_size);
>         printf("Phdr_load(): alloc dataspace at physical address [%p],
> size [%lx]\n", phys_addr, phys_size);
>         mm->prog_attach_ds(l4_addr_t(paddr), size, mem, 0, r_flags,
> "attaching rw ELF segment");
>         printf("Phdr_load(): attaching rw ELF segment: prog_attach_ds
> [l4_addr(%p) paddr(%p), offs %lu, size %lu, all segs cow? %d]\n",
> l4_addr_t(paddr), paddr, offs, size, mm->all_segs_cow());
>         mm->copy_ds(mem, 0, bin, offs, fsz + page_offs);
>       }
>     else
>       {
>         // map from file
>         mm->prog_attach_ds(l4_addr_t(paddr), size, bin, offs,
>                            r_flags | L4Re::Rm::Read_only,
>                            "attaching ro ELF segment");
>          printf("Phdr_load(): map from file (attaching ro ELF segment),
> prog_attach_ds [paddr = %p (%p), offs %lu, size %lu, all segs cow? %d]\n",
> l4_addr_t(paddr), paddr, offs, size, mm->all_segs\
> _cow());
>       }
>   }
>
>
> L4 Bootstrapper
>   Build: #140 Fri Dec 11 16:15:21 CET 2015, 4.8.3 20140320 (prerelease)
>   Scanning up to 512 MB RAM, starting at offset 32MB
>   Memory size is 512MB (60000000 - 7fffffff)
>   RAM: 0000000060000000 - 000000007fffffff: 524288kB
>   Total RAM: 512MB
>   Scanning fiasco
>   Scanning sigma0
>   Scanning moe
>   Moving up to 7 modules behind 61100000
>   moving module 02 { 6110a000-6114363f } -> { 611fa000-6123363f } [235072]
>   moving module 01 { 61100000-6110938b } -> { 611f0000-611f938b } [37772]
>   moving module 00 { 610a8000-610fff17 } -> { 61198000-611eff17 } [360216]
>   moving module 06 { 6108e000-610a7597 } -> { 6117e000-61197597 } [103832]
>   moving module 05 { 6108d000-6108d28f } -> { 6117d000-6117d28f } [656]
>   moving module 04 { 61032000-6108cc1f } -> { 61122000-6117cc1f } [371744]
>   moving module 03 { 61010000-61031473 } -> { 61100000-61121473 } [136308]
>   Loading fiasco
>   Loading sigma0
>   Loading moe
>   find kernel info page...
>   found kernel info page at 0x60002000
> Regions of list 'regions'
>     [ 60000000,  60000113] {      114} Root   mbi_rt
>     [ 60001000,  60001aff] {      b00} Kern   fiasco
>     [ 60002000,  60066fff] {    65000} Kern   fiasco
>     [ 60090000,  60096edf] {     6ee0} Sigma0 sigma0
>     [ 60098000,  6009e177] {     6178} Sigma0 sigma0
>     [ 60140000,  60172177] {    32178} Root   moe
>     [ 60178000,  601934ab] {    1b4ac} Root   moe
>     [ 61000000,  6100f537] {     f538} Boot   bootstrap
>     [ 61100000,  61197fff] {    98000} Root   Module
>   API Version: (87) experimental
>   Sigma0 config    ip:60090100 sp:00000000
>   Roottask config  ip:60140260 sp:00000000
>   Starting kernel fiasco at 600012c8
> Realview System ID: Rev=1 HBI=190 Build=f Arch=5 FPGA=00
> Hello from Startup::stage2
> Number of IRQs available at this GIC: 96
> FPU0: Arch: VFPv3(3), Part: VFPv3(30), r: 0, v: 9, i: 41, t: hard, p:
> dbl/sngl
> SERIAL ESC: allocated IRQ 37 for serial uart
> Not using serial hack in slow timer handler.
> Welcome to Fiasco.OC (arm)!
> L4/Fiasco.OC arm microkernel (C) 1998-2013 TU Dresden
> Rev: rexported compiled with gcc 4.8.3 for Realview    []
> Build: #202 Thu Dec 10 15:24:05 CET 2015
>
> Calibrating timer loop... done.
> MDB: use page size: 20
> MDB: use page size: 12
> SIGMA0: Hello!
>   KIP @ 60002000
>   allocated 4KB for maintenance structures
> SIGMA0: Dump of all resource maps
> RAM:------------------------
> [4:60000000;60000fff]
> [0:60067000;6008ffff]
> [0:60097000;60097fff]
> [0:6009f000;6013ffff]
> [4:60140000;60172fff]
> [0:60173000;60177fff]
> [4:60178000;60193fff]
> [0:60194000;610fffff]
> [4:61100000;61197fff]
> [0:61198000;7effffff]
> IOMEM:----------------------
> [0:0;5fffffff]
> [0:80000000;ffffffff]
> MOE: Hello world
> MOE: found 506512 KByte free memory
> MOE: found RAM from 60000000 to 7f000000
> MOE: allocated 496 KByte for the page array @0x6009f000
> MOE: virtual user address space [0-bfffffff]
> MOE: rom name space cap -> [C:501000]
>   BOOTFS: [61100000-61121474] [C:503000] l4re
>   BOOTFS: [61122000-6117cc20] [C:504000] ned
>   BOOTFS: [6117d000-6117d290] [C:505000] hello.cfg
>   BOOTFS: [6117e000-61197598] [C:506000] hello
> MOE: cmdline: moe rom/hello.cfg
> MOE: Starting: rom/ned rom/hello.cfg
>   STACK: b1000000 (8000)    KIP: affff000
> Moe::Dataspace alloc app stack for moe, dataspace phys addr = 0 size =
> 6017d070
> MOE: loading 'rom/ned'
> Phdr_load(): map from file (attaching ro ELF segment), prog_attach_ds
> [paddr = 0xb0000000 (0xb0000000), offs 0, size 102400, all segs cow? 0]
> Phdr_load(): alloc dataspace at physical address [(nil)], size [0]
> Phdr_load(): attaching rw ELF segment: prog_attach_ds [l4_addr(0xb0020000)
> paddr(0xb0020000), offs 131072, size 28672, all segs cow? 0]
> l4re_kernel:
> ARGC=2
> ARGV=b1007eb4
> ENVP=b1007ec0
> AUXP=b1007ec4
>   arg: 'rom/ned'
>   arg: 'rom/hello.cfg'
> l4re_kernel -> Loader::start binary dataspace [phys @addr = 61122000] size
> = [5ac20]
>   STACK: 80000000 (8000)    KIP: affff000
> Phdr_load(): map from file (attaching ro ELF segment), prog_attach_ds
> [paddr = 0x1000000 (0x1000000), offs 0, size 331776, all segs cow? 0]
> l4re_kernel: L4Re_app_model::alloc_ds dataspace phys @addr = [b0201e34]
> size = [b0010b58] flags 0
> Phdr_load(): alloc dataspace at physical address [0x10d4], size [1000]
> Phdr_load(): attaching rw ELF segment: prog_attach_ds [l4_addr(0x1058000)
> paddr(0x1058000), offs 360448, size 45056, all segs cow? 0]
> Ned says: Hi World!
> Ned: loading file: 'rom/hello.cfg'
>   STACK: b1000000 (8000)    KIP: affff000
> Phdr_load(): map from file (attaching ro ELF segment), prog_attach_ds
> [paddr = 0xb0000000 (0xb0000000), offs 0, size 102400, all segs cow? 0]
> Phdr_load(): alloc dataspace at physical address [0x2a], size [1]
> Phdr_load(): attaching rw ELF segment: prog_attach_ds [l4_addr(0xb0020000)
> paddr(0xb0020000), offs 131072, size 28672, all segs cow? 0]
>   STACK: b1000000 (8000)    KIP: affff000
> hello1  | l4re_kernel:
> hello1  | ARGC=1
> hello1  | ARGV=b1007f14
> hello1  | ENVP=b1007f1c
> hello1  | AUXP=b1007f20
> hello1  |   arg: 'rom/hello'
> hello1  | l4re_kernel -> Loader::start binary dataspace [phys @addr =
> 6117e000] size = [19598]
> hello1  |   STACK: 80000000 (8000)    KIP: affff000
> hello1  | Phdr_load(): map from file (attaching ro ELF segment),
> prog_attach_ds [paddr = 0x1000000 (0x1000000), offs 0, size 90112, all segs
> cow? 0]
> hello1  | l4re_kernel: L4Re_app_model::alloc_ds dataspace phys @addr =
> [b0201e34] size = [b0010b58] flags 0
> hello1  | Phdr_load(): alloc dataspace at physical address [0x10d4], size
> [1000]
> hello1  | Phdr_load(): attaching rw ELF segment: prog_attach_ds
> [l4_addr(0x1018000) paddr(0x1018000), offs 98304, size 32768, all segs cow?
> 0]
> hello1  | Hello World!
> Phdr_load(): map from file (attaching ro ELF segment), prog_attach_ds
> [paddr = 0xb0000000 (0xb0000000), offs 0, size 102400, all segs cow? 0]
> Phdr_load(): alloc dataspace at physical address [0x2a], size [1]
> Phdr_load(): attaching rw ELF segment: prog_attach_ds [l4_addr(0xb0020000)
> paddr(0xb0020000), offs 131072, size 28672, all segs cow? 0]
>   STACK: b1000000 (8000)    KIP: affff000
> Phdr_load(): map from file (attaching ro ELF segment), prog_attach_ds
> [paddr = 0xb0000000 (0xb0000000), offs 0, size 102400, all segs cow? 0]
> Phdr_load(): alloc dataspace at physical address [0x2a], size [1]
> Phdr_load(): attaching rw ELF segment: prog_attach_ds [l4_addr(0xb0020000)
> paddr(0xb0020000), offs 131072, size 28672, all segs cow? 0]
> hello2  | l4re_kernel:
> hello2  | ARGC=1
> hello2  | ARGV=b1007f14
> hello2  | ENVP=b1007f1c
> hello2  | AUXP=b1007f20
> hello2  |   arg: 'rom/hello'
> hello2  | l4re_kernel -> Loader::start binary dataspace [phys @addr =
> 6117e000] size = [19598]
> hello2  |   STACK: 80000000 (8000)    KIP: affff000
> hello2  | Phdr_load(): map from file (attaching ro ELF segment),
> prog_attach_ds [paddr = 0x1000000 (0x1000000), offs 0, size 90112, all segs
> cow? 0]
> hello2  | l4re_kernel: L4Re_app_model::alloc_ds dataspace phys @addr =
> [b0201e34] size = [b0010b58] flags 0
> hello2  | Phdr_load(): alloc dataspace at physical address [0x10d4], size
> [1000]
> hello2  | Phdr_load(): attaching rw ELF segment: prog_attach_ds
> [l4_addr(0x1018000) paddr(0x1018000), offs 98304, size 32768, all segs cow?
> 0]
> hello2  | Hello World!
>   STACK: b1000000 (8000)    KIP: affff000
> Phdr_load(): map from file (attaching ro ELF segment), prog_attach_ds
> [paddr = 0xb0000000 (0xb0000000), offs 0, size 102400, all segs cow? 0]
> Phdr_load(): alloc dataspace at physical address [0x2a], size [1]
> Phdr_load(): attaching rw ELF segment: prog_attach_ds [l4_addr(0xb0020000)
> paddr(0xb0020000), offs 131072, size 28672, all segs cow? 0]
> hello4  | l4re_kernel:
> hello4  | ARGC=1
> hello4  | ARGV=b1007f14
> hello4  | ENVP=b1007f1c
> hello4  | AUXP=b1007f20
> hello4  |   arg: 'rom/hello'
> hello4  | l4re_kernel -> Loader::start binary dataspace [phys @addr =
> 6117e000] size = [19598]
> hello4  |   STACK: 80000000 (8000)    KIP: affff000
> hello4  | Phdr_load(): map from file (attaching ro ELF segment),
> prog_attach_ds [paddr = 0x1000000 (0x1000000), offs 0, size 90112, all segs
> cow? 0]
> hello4  | l4re_kernel: L4Re_app_model::alloc_ds dataspace phys @addr =
> [b0201e34] size = [b0010b58] flags 0
> hello4  | Phdr_load(): alloc dataspace at physical address [0x10d4], size
> [1000]
> hello4  | Phdr_load(): attaching rw ELF segment: prog_attach_ds
> [l4_addr(0x1018000) paddr(0x1018000), offs 98304, size 32768, all segs cow?
> 0]
> hello4  | Hello World!
> hello3  | l4re_kernel:
> hello3  | ARGC=1
> hello3  | ARGV=b1007f14
> hello3  | ENVP=b1007f1c
> hello3  | AUXP=b1007f20
> hello3  |   arg: 'rom/hello'
> hello3  | l4re_kernel -> Loader::start binary dataspace [phys @addr =
> 6117e000] size = [19598]
> hello3  |   STACK: 80000000 (8000)    KIP: affff000
> hello3  | Phdr_load(): map from file (attaching ro ELF segment),
> prog_attach_ds [paddr = 0x1000000 (0x1000000), offs 0, size 90112, all segs
> cow? 0]
> hello3  | l4re_kernel: L4Re_app_model::alloc_ds dataspace phys @addr =
> [b0201e34] size = [b0010b58] flags 0
> hello3  | Phdr_load(): alloc dataspace at physical address [0x10d4], size
> [1000]
> hello3  | Phdr_load(): attaching rw ELF segment: prog_attach_ds
> [l4_addr(0x1018000) paddr(0x1018000), offs 98304, size 32768, all segs cow?
> 0]
> hello3  | Hello World!
> hello1  | Hello World!
> hello2  | Hello World!
> hello4  | Hello World!
> hello3  | Hello World!
> hello1  | Hello World!
> hello2  | Hello World!
> hello4  | Hello World!
> hello3  | Hello World!
> hello1  | Hello World!
> hello2  | Hello World!
> hello4  | Hello World!
> hello3  | Hello World!
>
>
> On Mon, Nov 30, 2015 at 3:33 PM, Mahdi Aichouch <foxmehdi at gmail.com>
> wrote:
>
>> Hello Adam,
>>
>> I have a question about the way how L4-Fiasco manages the page tables of
>> L4 tasks.
>>
>> I would like to know if it might happen that L4-Fiasco uses shared page
>> tables between multiples page directories.
>> For instance, let's say that two L4 tasks have access to one shared
>> library. Is it possible that the page tables of the shared library could be
>> used in both page directories.
>>
>> My second question concerns the physical memory layout of L4-Fiasco and
>> L4Linux.
>>
>> Below is a drawing of the physical memory layout of L4-Fiasco and L4Linux
>> running on a Qemu arm versatile express cortex-a9.
>> L4-Fiasco is configured to use 256MB.
>>
>> My question is related to the physical memory L4-Fiasco where stores the
>> UTCBs of L4 tasks?
>> From my tracing it seems that it uses the last 16MB of the physical
>> memory to store kernel objects.
>> Could you please tell me where in physical memory L4-Fiasco stores UTCBs
>> area.
>>
>> Thank you very much in advance.
>>
>> Best regards,
>> Mahdi
>>
>> +-------------------------------------------------------------------+
>> |0x6000 0000 |1.5GB  |1536MB  | 0MB
>> | | | | Module Boot Information
>> |0x6000 00E3 |  |1536MB  |
>> |---------------------------------|---------------|------------------|
>> |0x6000 1000                   |                  |                      |
>> |                                        |                  |
>>          | Fiasco
>> |0x6000 1AFF                   |                  |                     |
>> |---------------------------------|---------------|------------------|
>> |0x6000 2000                   |                  |                      |
>> |                                        |                  |
>>          | Fiasco
>> |0x6007 6FFF                   |                  |                      |
>> |---------------------------------|---------------|------------------|
>> |0x6009 0000                   |                  |                      |
>> |                                        |                  |
>>          | Sigma0
>> |0x6009 E177                   |                  |                      |
>> |---------------------------------|---------------|------------------|
>> |0x6014 0000                   |                  |                      |
>> |                                        |                  |
>>          | MOE
>> |0x6017 27AB                   |                  |                      |
>> |---------------------------------|---------------|------------------|
>> |0x6017 8000                   |                  |                      |
>> |                                        |                  |
>>          | MOE
>> |0x6019 34AB                   |                  |                      |
>> |---------------------------------|---------------|------------------|
>> |0x6026 C000                   |                  |1538MB        |
>> |                                        |                  |
>>          | L4Linux Binary
>> |0x606D A394                  |                  |1542MB         |
>> |                                        |                  |
>>         |
>> |                                        |                  |
>>         |
>> |                                        |                  |
>>         |
>> |---------------------------------|---------------|------------------|
>> |0x6100 0000                   |                  |1552MB        |
>> |                                        |                  |
>>          | Bootstrap
>> |0x6100 F4FF |  |  |
>> |---------------------------------|---------------|------------------|
>> |0x6110 0000                   |                  |1553MB        |
>> |                                        |                  |
>>          | Modules
>> |0x6113 BFFF | |  |
>> |---------------------------------|---------------|------------------|
>> |0x6113 C000                  |                  |1553MB         | Start
>> of Memory Handed to Sigma0
>> | |  |  |
>> |0x6169 8000                   |                  |1558MB  |
>> |                                        |                  |
>>          | RAM DISK L4Linux
>> |0x6199 7000                   |                  |1561MB        |
>> |---------------------------------|---------------|------------------|
>> |0x61A0 0000                   |                  |1562MB        |
>> | |  |                      |
>> |                                        |                  |
>>          | RAM L4Linux = 64MB
>> |  |  |  |
>> |0x659F FFFF                  |                  |1627MB        |
>> |---------------------------------|---------------|------------------|
>> |                                        |                  |
>>         |
>> |                                        |                  |
>>         |
>> |                                        |                  |
>>         |
>> |                                        |                  |
>>         |
>> |                                        |                  |
>>         |
>> |                                        |                  |
>>         |
>> |                                        |                  |
>>         |
>> |0x6EFF FFFF                |                  |1776MB        | End of
>> Memory Handed to Sigma0
>> |---------------------------------|---------------|------------------|
>> |0x6F00 0000 |              |1776MB  | 240MB
>> |  |  |  |  memory reserved for L4 Fiasco kernel
>> |0x6FFF FFFF |1.75GB  |1792MB  | 256MB
>> +------------------------------------------------------------------+
>>
>>
>>
>>
>>
>> On Fri, Nov 20, 2015 at 4:00 PM, Mahdi Aichouch <foxmehdi at gmail.com>
>> wrote:
>>
>>> Hello Adam,
>>>
>>> The UTCB is allocated as a physical memory page, which is a 4KB if a
>>> small page is used, right?
>>>
>>> Do you think that it is possible to allocated a 16KB or 32KB UTCB area,
>>> and to align their physical start address on 16KB or 32KB?
>>>
>>> Thank you in advance for your answer.
>>>
>>> Best regards,
>>>
>>> Mahdi
>>>
>>>
>>> On Mon, Oct 26, 2015 at 10:24 AM, Mahdi Aichouch <foxmehdi at gmail.com>
>>> wrote:
>>>
>>>> Hello Adam,
>>>>
>>>> I have a question about the UTCB area.
>>>> If I understand correctly, the UTCB is physical memory page that is
>>>> allocated in the kernel physical memory space, then mapped into the user
>>>> and kernel virtual memory space, right?
>>>>
>>>> Thank you very much for your answer.
>>>>
>>>> Best regards,
>>>> Mahdi
>>>>
>>>>
>>>> On Wed, Oct 7, 2015 at 3:42 PM, Mahdi Aichouch <foxmehdi at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello Adam,
>>>>>
>>>>> In order to be sure that I correctly understand how Dataspace and
>>>>> Memory Allocator work, I tried an example where Dataspace are created using
>>>>> the "L4Re::Mem_alloc::Continuous and L4Re::Mem_alloc::Pinned" flags. This
>>>>> will ensure that the allocated physical memory is contiguous and can not be
>>>>> moved, right?
>>>>>
>>>>> My second question concerns the way how an L4 task is loaded into
>>>>> memory. Do you think that it is possible to make all segments of an L4 user
>>>>> program to be adjacent in physical memory. As an example, given one L4 user
>>>>> program we would like to have the following configuration:
>>>>>
>>>>> Physical memory
>>>>>
>>>>> 0x000000       0MB
>>>>>
>>>>> 0x100000       1MB
>>>>>                                   text
>>>>> 0x200000       2MB
>>>>>                                   data
>>>>> 0x300000       3MB
>>>>>                                   stack
>>>>> 0x400000       4MB
>>>>>                                   heap
>>>>> 0x500000       5MB
>>>>>
>>>>> (the memory addresses are given here for illustration purpose)
>>>>>
>>>>> From my tracing of Moe, L4re and libloader using Moe::Dataspace::phys(
>>>>> ) function,  I saw that some areas were adjacent and other were not. Could
>>>>> you please give an explanation of how Moe and l4re load a user program from
>>>>> a disk into memory.
>>>>>
>>>>> Thank you very much in advance.
>>>>>
>>>>> kind regards,
>>>>> Mahdi
>>>>>
>>>>>
>>>>> On Mon, Sep 28, 2015 at 10:44 AM, Mahdi Aichouch <foxmehdi at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello Adam,
>>>>>>
>>>>>> > An application is typically composed of multiple memory regions in
>>>>>> > virtual memory. Do you mean you want all those regions to be physically
>>>>>> > contiguous, such as text-segment, bss and stacks? This should be
>>>>>> > possible by using a memory allocator that makes sure this is the case.
>>>>>> > However, currently, there is only the possibility to have dataspaces
>>>>>> > physicall contiguous.
>>>>>>
>>>>>> This exactly what I mean, that is, text-segment, bss, data, stack,
>>>>>> and heap regions have to be contiguously allocated for Fiasco kernel,
>>>>>> sigma0, moe, L4Linux, and for each created L4 task.
>>>>>> My use case requires that each created L4 task has to be provided
>>>>>> with a static fixed physical memory segment, and cannot exceed its
>>>>>> allocated memory segment.
>>>>>>
>>>>>> Currently the memory allocator is present in moe package, right?
>>>>>> Thus, a new memory allocator should to be added to that package I
>>>>>> guess, right?
>>>>>> If not, could you please suggest a place in the code base where a new
>>>>>> memory allocator has to be added.
>>>>>>
>>>>>> I would like to implement a mechanism that allow to know for each
>>>>>> created L4 task which physical frame a virtual page is mapped to. The
>>>>>> functionality provided by such a service are similar to
>>>>>> pagemap [1] service in Linux kernel.
>>>>>>
>>>>>> Is such a service could be implemented at userspace in L4re?
>>>>>> Does Fiasco O.C provide the necessary mechanism to implement it?
>>>>>> If yes, could you please suggest a set functions that should be used.
>>>>>>
>>>>>> Thank you very much for your answer.
>>>>>> Best regards,
>>>>>>
>>>>>> Mahdi
>>>>>>
>>>>>> [1] https://www.kernel.org/doc/Documentation/vm/pagemap.txt
>>>>>>
>>>>>> On Wed, Sep 16, 2015 at 11:45 AM, Mahdi Aichouch <foxmehdi at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hello Adam,
>>>>>>>
>>>>>>> I updated the schema of the memory mapping of L4Linux and Fiasco O.C
>>>>>>> according to your corrections.
>>>>>>> Could you please take a look at it and tell me if everything is
>>>>>>> correct.
>>>>>>>
>>>>>>> I have some questions about the way Fiasco O.C µ-kernel loads the L4
>>>>>>> tasks into physical memory.
>>>>>>>
>>>>>>> If I correctly understood, when Fiasco O.C creates a new L4 task it
>>>>>>> uses a copy-on-write
>>>>>>> mechanism to allocate physical pages in memory, right?
>>>>>>> That means, the physical memory region allocated to an L4 task might
>>>>>>> not be formed
>>>>>>> by a contiguous set of physical pages.
>>>>>>>
>>>>>>> Is it possible to make Fiasco O.C reserves a physical memory region
>>>>>>> composed by a
>>>>>>> set of contiguous physical memory pages when creating an L4 task?
>>>>>>>
>>>>>>> If the answer is yes, could you please suggest an example showing
>>>>>>> the way to do it.
>>>>>>>
>>>>>>> My second question concerns the L4Linux tasks. Could you please tell
>>>>>>> me some
>>>>>>> explanation about the way L4Linux and Fiasco O.C load into physical
>>>>>>> memory the L4Linux tasks,
>>>>>>> and where can I find the code that is doing these operations.
>>>>>>>
>>>>>>> Thank you very much in advance.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Mahdi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 9, 2015 at 3:28 PM, Mahdi Aichouch <foxmehdi at gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hello Adam,
>>>>>>>>
>>>>>>>> In order to document my investigation of memory management in
>>>>>>>> L4Linux,
>>>>>>>> I draw an abstract representation of the memory mapping of
>>>>>>>> L4Linux's tasks
>>>>>>>> virtual memory into L4Linux "real" memory and into physical memory.
>>>>>>>>
>>>>>>>> Could you please take a look at my schema and tell if it correctly
>>>>>>>> represents
>>>>>>>> the memory mapping in L4Linux.
>>>>>>>>
>>>>>>>> Any corrections and remarks are welcome.
>>>>>>>>
>>>>>>>> Thank you very much in advance.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Mahdi
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jul 31, 2015 at 5:03 PM, Mahdi Aichouch <foxmehdi at gmail.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> Hello Adam,
>>>>>>>>>
>>>>>>>>> Is it possible to know where a UTCB memory area is allocated in
>>>>>>>>> the physical memory space of a thread.
>>>>>>>>> If the answer is yes, could you please suggest a way to do it.
>>>>>>>>>
>>>>>>>>> Thank you very much for your answer.
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> Mahdi
>>>>>>>>>
>>>>>>>>> On Tue, Jul 28, 2015 at 4:10 PM, Mahdi Aichouch <
>>>>>>>>> foxmehdi at gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hello Adam,
>>>>>>>>>>
>>>>>>>>>> I have a question about the way Fiasco.OC handles IPC.
>>>>>>>>>>
>>>>>>>>>> If we take a simple example of one thread in address space A that
>>>>>>>>>> sends an array of characters to a second
>>>>>>>>>> thread located in an address space B.
>>>>>>>>>> Since such an array might be large and cannot be transferred
>>>>>>>>>> using the registers.
>>>>>>>>>>
>>>>>>>>>> How it is transferred to the second thread address space?
>>>>>>>>>>
>>>>>>>>>> Is it at first allocated on the first thread stack, then copied
>>>>>>>>>> by Fiasco kernel to
>>>>>>>>>> the second thread address space?
>>>>>>>>>>
>>>>>>>>>> Thank you very much for your answer.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Mahdi
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Fri, Jul 24, 2015 at 9:12 AM, Mahdi Aichouch <
>>>>>>>>>> foxmehdi at gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Hello Adam,
>>>>>>>>>>>
>>>>>>>>>>> What I mean by accessing memory partition is: does Fiasco.OC
>>>>>>>>>>> accesses memory
>>>>>>>>>>> reserved for L4Linux when handling system-call issued by L4Linux
>>>>>>>>>>> guest for example
>>>>>>>>>>> or any other operation.
>>>>>>>>>>>
>>>>>>>>>>> Thank you very much for your answer.
>>>>>>>>>>>
>>>>>>>>>>> Best regards,
>>>>>>>>>>> Mahdi
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Thu, Jul 23, 2015 at 5:32 PM, Mahdi Aichouch <
>>>>>>>>>>> foxmehdi at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hello Adam,
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to know if Fiasco.OC kernel accesses memory
>>>>>>>>>>>> partition allocated to an L4Linux guest?
>>>>>>>>>>>> And for what reasons it has to do it?
>>>>>>>>>>>>
>>>>>>>>>>>> Thank you very much for your answer.
>>>>>>>>>>>>
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>> Mahdi
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Jul 22, 2015 at 3:19 PM, Mahdi Aichouch <
>>>>>>>>>>>> foxmehdi at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hello Adam,
>>>>>>>>>>>>>
>>>>>>>>>>>>> According to Fiasco O.C/L4re documentation Sigma0 is the root
>>>>>>>>>>>>> pager,
>>>>>>>>>>>>> that is, it is responsible of resolving page fault of
>>>>>>>>>>>>> user-level tasks, right?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Knowing that L4Linux is created as a user-level task, thus any
>>>>>>>>>>>>> memory page fault occurring
>>>>>>>>>>>>> in L4Linux or its user processes logically has to be handled
>>>>>>>>>>>>> through Sigma0.
>>>>>>>>>>>>>
>>>>>>>>>>>>> However, as you previously mentioned in one of your answers, a
>>>>>>>>>>>>> handling of
>>>>>>>>>>>>> a page fault occurring in L4Linux does not involve any L4Re
>>>>>>>>>>>>> object including Sigma0.
>>>>>>>>>>>>>
>>>>>>>>>>>>> My question is: what configuration and / or operations have
>>>>>>>>>>>>> been made
>>>>>>>>>>>>> in order to force that a memory page fault in L4Linux has to
>>>>>>>>>>>>> be handled
>>>>>>>>>>>>> only by Fiasco and L4Linux and not going through L4Re objects?
>>>>>>>>>>>>> And where these operations are written in the source code.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you very much for your answer.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best regards.
>>>>>>>>>>>>> Mahdi
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, Jul 21, 2015 at 4:06 PM, Mahdi Aichouch <
>>>>>>>>>>>>> foxmehdi at gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hello Adam,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I would like to understand how L4 Fiasco manages the virtual
>>>>>>>>>>>>>> memory of a L4Linux guest.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does L4 Fiasco maintains a "shadow page table" in order to
>>>>>>>>>>>>>> perform a two-level memory address translation:
>>>>>>>>>>>>>> guest virtual memory --> guest real memory --> host physical
>>>>>>>>>>>>>> memory?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If the answer is yes, where the "shadow page table" is
>>>>>>>>>>>>>> maintained? which L4 Fiasco object
>>>>>>>>>>>>>> is responsible of this operation?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If we suppose that an L4Linux guest has for example a 64MB of
>>>>>>>>>>>>>> fixed physical memory region,
>>>>>>>>>>>>>> in case a new L4Linux user task arrives and there is no
>>>>>>>>>>>>>> available space to allocate
>>>>>>>>>>>>>> a new page for this task, an already used page has to be
>>>>>>>>>>>>>> unmapped, right?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If the answer is yes, then where the dirty page will be
>>>>>>>>>>>>>> swapped?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thank you very much for your answer.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>> Mahdi
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jul 20, 2015 at 4:36 PM, Mahdi Aichouch <
>>>>>>>>>>>>>> foxmehdi at gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hello Adam,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If I correctly understood, and If we suppose that an L4Linux
>>>>>>>>>>>>>>> instance
>>>>>>>>>>>>>>> is started for example with this command line options:
>>>>>>>>>>>>>>> ... earlyprintk=1 em=64M ...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This means that a 64MB of physical memory region composed of
>>>>>>>>>>>>>>> a set of contiguous physical frames is allocated to L4Linux, right?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> L4Linux will use a part of this 64MB of physical memrory for
>>>>>>>>>>>>>>> its own kernel execution, and
>>>>>>>>>>>>>>> the rest of physical memory space will be used by L4Linux to
>>>>>>>>>>>>>>> load user-level programs
>>>>>>>>>>>>>>> and allocate physical memory for them, right?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If a user-level program on top of L4Linux generates a
>>>>>>>>>>>>>>> page-fault.
>>>>>>>>>>>>>>> Are the L4 Fiasco kernel and L4re involved in the execution
>>>>>>>>>>>>>>> flow to handle the page-fault?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thank you very much for your clarification.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Mahdi
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Jul 17, 2015 at 10:36 AM, Mahdi Aichouch <
>>>>>>>>>>>>>>> foxmehdi at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello Adam,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The memory regions are exclusive. Specifying exactly which physical
>>>>>>>>>>>>>>>>> memory an L4Linux is getting is currently not possible but I guess
>>>>>>>>>>>>>>>>> you're using the numbers just as an example?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes, I am giving these numbers as an example.
>>>>>>>>>>>>>>>> However, is it possible to know what are the start address and the end address
>>>>>>>>>>>>>>>> of a physical memory partition allocated to a L4Linux instance?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The memory is completely mapped initially, so no page fault should
>>>>>>>>>>>>>>>>> happen. As probably nobody will take it away again it should also stay
>>>>>>>>>>>>>>>>> like this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Does this apply also to user-level programs executed on top of L4Linux.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You can put showpfexc=1 on the cmdline to see any in-kernel page fault.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There shouldn't be any (except in the outside wrapper code as I see
>>>>>>>>>>>>>>>>> which can be changed by launching L4Linux with the eager_map flag).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Could please give some explanation about what is the wrapper code? And Where to set the "eager_map flag" option?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thank you very much for your answer!
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Mahdi
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Wed, Jul 15, 2015 at 11:53 AM, Mahdi Aichouch <
>>>>>>>>>>>>>>>> foxmehdi at gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I have some questions concerning memory management in
>>>>>>>>>>>>>>>>> Fiasco O.C  + L4re.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I would like to test two L4Linux instances, and for each
>>>>>>>>>>>>>>>>> L4Linux
>>>>>>>>>>>>>>>>> instance I want to reserve one static fixed physical
>>>>>>>>>>>>>>>>> memory partition.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> For instance, one 128MB for the first L4Linux and one
>>>>>>>>>>>>>>>>> 128MB for the second.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Knowing that Fiasco O.C. uses "on demand paging" to
>>>>>>>>>>>>>>>>> allocate pages for
>>>>>>>>>>>>>>>>> user tasks, is it possible that each partition of L4Linux
>>>>>>>>>>>>>>>>> could be allocated
>>>>>>>>>>>>>>>>> a static physical memory region composed of contiguous
>>>>>>>>>>>>>>>>> physical frames.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> For instance, one memory region starting from 128MB to
>>>>>>>>>>>>>>>>> 256MB for the first L4Linux,
>>>>>>>>>>>>>>>>> and second memory region from 256MB to 512MB for the
>>>>>>>>>>>>>>>>> second L4Linux.
>>>>>>>>>>>>>>>>> Each memory region is allocated exclusively to one L4Linux
>>>>>>>>>>>>>>>>> instance.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I would like to know if it is possible to load all the
>>>>>>>>>>>>>>>>> code + data of a L4Linux instance
>>>>>>>>>>>>>>>>> into its reserved memory partition, so no page fault will
>>>>>>>>>>>>>>>>> be encountered during runtime.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Is it possible to tell me if these above operations could
>>>>>>>>>>>>>>>>> be realized in Fiasco O.C and L4re?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> If the answer is yes, is it possible to tell me what are
>>>>>>>>>>>>>>>>> the objects that should be used or
>>>>>>>>>>>>>>>>> adapted in order to implement these?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What are the issues that I should pay attention to?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Many thanks in advance for your answer.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Mahdi
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20151214/48ee5958/attachment-0001.html>


More information about the l4-hackers mailing list