Question about memory management in L4 Fiasco O.C + L4re
Mahdi Aichouch
foxmehdi at gmail.com
Mon Jan 4 17:03:49 CET 2016
Hello Adam,
I combined the loader flags
"L4.Ldr_flags.eager_map+L4.Ldr_flags.pinned_segs" in order to create fixed
memory region for the text and data segments of an L4 task*. *And to be
able to see their physical address using phys( ) method of Dataspace
object. But, looking at the traces I didn't see any difference. After
digging into the code where the Dataspace objects are created I saw that
for instance in the following method from the file
pkg/l4re_kernel/server/src/loader.cc :
L4Re_app_model::Dataspace
L4Re_app_model::alloc_ds(unsigned long size) const
{
Dataspace mem = chkcap(Global::cap_alloc.alloc<L4Re::Dataspace>(),
"ELF loader: could not allocate capability");
chksys(Global::allocator->alloc(size, mem, (Global::l4re_aux->ldr_flags &
L4RE_AUX_LDR_FLAG_PINNED_SEGS) ? L4Re::Mem_alloc::Pinned : 0 ), "loading
writabel ELF segment");
return mem;
}
The value of Global::l4re_aux->ldr_flags is equal to 0. And given the
result of the test the created Dataspace is not pinned, because 0 is given
as argument to alloc( ) method.
I was unable to find out why the attribute Global::l4re_aux->ldr_flags is
not equal to L4.Ldr_flags.eager_map+L4.Ldr_flags.pinned_segs, as I was
expecting.
Could you please clarify this point.
For my test, I modified the precedent code as follow :
chksys(Global::allocator->alloc(size, mem, /*(Global::l4re_aux->ldr_flags &
L4RE_AUX_LDR_FLAG_PINNED_SEGS) ?*/ L4Re::Rm::Eager_map |
L4Re::Mem_alloc::Pinned /*:0*/ ), "loading writabel ELF segment");
Then, in the traces I was I able to see the physical address of the created
Dataspace objects.
After that, I tested L4Linux and I saw that the physical addresses of the
created Dataspace object of text and data segments when loading L4Linux
binary have for example the following value :
l4linux | l4re_kernel: Loader::alloc_app_stack stack dataspace phys addr =
605b1000 size = 1000
l4linux | Global loader flags (Global::l4re_aux->ldr_flags) = 0
l4linux | l4re_kernel: L4Re_app_model::alloc_ds dataspace phys @addr =
[605b2000] size = [3f9000] flags 0
l4linux | Phdr_load(): dataspace at physical address [0x605b2000], size
[3f9000]
l4linux | Phdr_load(): map from file (attaching ro ELF segment),
prog_attach_ds [paddr = 0xa8000000 (0xa80segments00000), offs 0, size
4165632, all segs cow? 0]
l4linux | Global loader flags (Global::l4re_aux->ldr_flags) = 0
l4linux | l4re_kernel: L4Re_app_model::alloc_ds dataspace phys @addr =
[60aaf000] size = [2000] flags 0
l4linux | Phdr_load(): dataspace at physical address [0x60aaf000], size
[2000]
l4linux | Phdr_load(): attaching rw ELF segment: prog_attach_ds
[l4_addr(0xa8400000) paddr(0xa8400000), offs 4194304, size 8192, all segs
cow? 0]
Looking in the trace from the main( ) function in L4Linux we can see that
the physical address of the text and data areas of L4Linux are different
from the precedents value printed using the phys( ) method of the
corresponding Dataspace objects. As we can see below in the lines showing
the physical value of stext - etext, sdata - edata areas :
...
l4linux | L4LINUX: Ma DBG: Virtual Address 00000000 End 00000000
l4linux | Physical Address 00000000 End 00000000
l4linux | L4LINUX: Ma DBG: Starting binary at 0x2000360, argc=14
argv=0xafff4f6c *argv=0xb1007ff0 argv0=rom/vmlinuz.arm
l4linux | External resolver is at 0xa800075c
l4linux | ======> L4Linux starting... <========
l4linux | Linux version 3.16.0-l4 (aichouch at aichouch-ThinkCentre-M90) (gcc
version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) )
#57 SMP Mon Jan 4 15:16:18 CET 2016
l4linux | Binary name: rom/vmlinuz.arm
l4linux | This is an AEABI build.
l4linux | Linux kernel command line (13 args): mem=128M
l4memtype=pinned,continuous console=ttyLv0 l4x_rd=rom/ramdisk-arm.rd
root=1:0 ramdisk_size=49152 rw init=/bin/sh earlyprintk=1 showpfexc=1
showghost=1 print-fatal-signals=1 l4shmnet.add=shmns,macparCPU mapping
(l:p)[1]: 0:0
l4linux | Image: 020000a0 - 02600000 [6143 KiB].
l4linux | Areas: Text: 020000a0 - 023b2000 [3783kB] (a bit longer)
l4linux | Data: 023b2000 - 023dd460 [173kB]
l4linux | Initdata: 02387000 - 023b1a00 [170kB]
l4linux | BSS: 023e239c - 024a6780 [784kB]
l4linux | Device scan:
l4linux | Device: L4ICU
l4linux | Device: imx6q-fec.dev
l4linux | MEM: 02188000 - 0218bfff
l4linux | IRQ: 00000096 - 00000096
l4linux | IRQ: 00000097 - 00000097
l4linux | Device: dmamem
l4linux | MEM: 60ab1000 - 60b30fff
l4linux | Device scan done.
l4linux | L4LINUX: Ma DBG: l4lx_thread_create: Created thread 416 (cpu0)
(u:b3000e00, v:b3000c00, sp:023b3fa4)
l4linux | main thread will be 416
l4linux | l4x_register_pointer_section: addr = 02000000 size = 4878336
l4linux | section-with-init: Virt: 0x2000000 to 0x24a677f [4761 KiB]
l4linux | section-with-init: Phys: 0x60b33000 to 0x60fd977f, [4761 KiB]
l4linux | Main thread running, waiting...
l4linux | Main thread running, waiting...
l4linux | stext virt 020000a0, phys 60b330a0
l4linux | etext virt 023b2000, phys 60ee5000
l4linux | sdata virt 023b2000, phys 60ee5000
l4linux | edata virt 023dd460, phys 60f10460
l4linux | L4x: Memory size: 128MB
l4linux | L4x: Setting superpages for main memory
l4linux | L4x: Adjusted memory start: 02000000
l4linux | Main memory: Virt: 0x2600000 to 0xa5fffff [131072 KiB]
l4linux | Main memory: Phys: 0x64800000 to 0x6c7fffff, [131072 KiB]
l4linux | l4x: vmalloc area: 0a600000 - 12600000
l4linux | l4x_register_pointer_section: addr = 02000000 size = 4878336
l4linux | text: Virt: 0x2000000 to 0x24a677f [4761 KiB]
l4linux | text: Phys: 0x60b33000 to 0x60fd977f, [4761 KiB]
l4linux | Booting Linux on physical CPU 0x0
l4linux | Linux version 3.16.0-l4 (aichouch at aichouch-ThinkCentre-M90) (gcc
version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29) )
#57 SMP Mon Jan 4 15:16:18 CET 2016
l4linux | CPU: Fiasco [410fc090] revision 0 (ARMv7), cr=00000000
l4linux | CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing
instruction cache
l4linux | Machine: L4
l4linux | Ignoring unrecognised tag 0x00000000
l4linux | bootconsole [earlykdb0] enabled
l4linux | Forcing write-allocate cache policy for SMP
l4linux | Forcing shared mappings for SMP
l4linux | Memory policy: Data cache writealloc
l4linux | Page fault: addr = bffff003 pc = 0238aba0 (rw, T)
l4linux | Forward PF to our pager
l4linux | Loading: rom/ramdisk-arm.rd
l4linux | INITRD: Size of RAMdisk is 49152KiB
l4linux | INITRD: 12600000 - 15600000
...
Could you please explain why there is a difference in the physical
addresses of the Dataspaces representing the text and data sections when
loading L4Linux binary, and the physical addresses of these sections when
L4Linux is booting.
Thank you very much in advance.
Best regards,
Mahdi
On Mon, Dec 14, 2015 at 4:47 PM, Mahdi Aichouch <foxmehdi at gmail.com> wrote:
> 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/20160104/9630b0ca/attachment.html>
More information about the l4-hackers
mailing list