Physical memory allocation to L4linux
Masti Ramya Jayaram
rmasti at inf.ethz.ch
Mon Sep 15 20:25:37 CEST 2014
Hey Adam,
Thanks for the input. I will try changing one of the suggested functions.
It would be great out of curiosity if you could elucidate why the following occurs.
I see that there is a new iomem region being created and this happens only when I try to read from the mapped region - not until then. But none of this reaches the kernel or maybe I am not sure where to look..
In fact, I see that the init_mem file parses the kernel memory descriptors to find the regions. So under what circumstances does sigma0 go back to the kernel for mem/io?
Thanks a lot!
Ramya
> On 15 Sep 2014, at 00:38, "Adam Lackorzynski" <adam at os.inf.tu-dresden.de> wrote:
>
>> On Fri Sep 12, 2014 at 16:34:17 +0000, Masti Ramya Jayaram wrote:
>> I realized that the best place to modify sigma0's capabilities are
>> when it is created. I see that this happens in
>> kernel/fiasco/src/kern/kernel_thread-std.cpp in the init_workload()
>> function. I do not exactly understand how sigma0 gathers all the
>> capabilities - the code is a little hard to parse for me. Could
>> someone explain this to me? Is there a way to pass only limited
>> capabilities to sigma0 -aka, allow the default and then prune the
>> resource tree?
>
> So, I've changed my mind, let's not modify the kernel but sigma0. This
> seems easier to me. As sigma0 is the root of memory this should not be a
> problem and can be argued.
> Sigma0 handles memory at first-come-first-serve approach and only gives
> it out once, so allocating it before servicing client requests should
> hide it from clients (see memmap.cc). However, there's also an unmap
> call which would need to be handled to not free it again. Another
> approach could be to exclude the memory region when initializing the
> internal data structures in init_mem.cc. Whatever works/fits better.
>
>
>
>
> Adam
> --
> Adam adam at os.inf.tu-dresden.de
> Lackorzynski http://os.inf.tu-dresden.de/~adam/
>
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
More information about the l4-hackers
mailing list