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

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 <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
>> 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 <[email protected]>
>>> 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 <[email protected]>
>>>> 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 <[email protected]>
>>>>> 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 <[email protected]>
>>>>>> 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 <[email protected]
>>>>>>> > 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

_______________________________________________
l4-hackers mailing list
[email protected]
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers