Question about memory management in L4 Fiasco O.C + L4re
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
Hi, On Wed Jul 15, 2015 at 11:53:50 +0200, Mahdi Aichouch wrote:
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.
This is actually the default behavior. L4Linux is acquiring physical contiguous memory and this is also static, i.e. it is not changing afterwards.
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.
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?
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.
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.
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?
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). Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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
Hi, On Fri Jul 17, 2015 at 10:36:35 +0200, Mahdi Aichouch wrote:
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?
Yes, this is done in L4Linux as it is for example required for device drivers. virt_to_phys will yield the proper physical memory address. L4Linux is also printing the virt-phys pairs on bootup.
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.
User-level programs are paged normally. Any possible page fault avoidance needs to be done with Linux means.
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?
With the wrapper code I mean the glue layer that gates between the internal Linux system and the outside L4Re system. See arch/l4/boot. L4.default_loader:start({ ldr_flags = L4.Ldr_flags.eager_map }, ...); Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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
Hi, On Mon Jul 20, 2015 at 16:36:52 +0200, Mahdi Aichouch wrote:
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?
Yes.
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?
Yes.
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?
Only Fiasco is involved because the host kernel will get the page fault exception from the CPU. Fiasco will then invoke the L4Linux kernel with appropriate info on the page fault to let L4Linux handle it. L4Re is not involved here. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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
Hi, On Tue Jul 21, 2015 at 16:06:33 +0200, Mahdi Aichouch wrote:
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?
There are two page tables, one is in L4Linux and that maps process memory to Linux internal memory (in a strict sense it's virtual to virtual but you could also understand that as guest virtual to guest physical). The other page table is the real one, maintained by Fiasco. This one maps from virtual to physical, it's a normal process page table. There's also no nesting/chaining here.
If the answer is yes, where the "shadow page table" is maintained? which L4 Fiasco object is responsible of this operation?
A page table is part of each L4::Task object.
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?
Yes, probably, whatever Linux is doing in this case.
If the answer is yes, then where the dirty page will be swapped?
Whatever Linux is doing for that, so for example to swap space on disk, or the fork will fail. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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
On Wed Jul 22, 2015 at 15:19:39 +0200, Mahdi Aichouch wrote:
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?
No. Every thread has a pager which is another thread in the system. So whenever a thread causes a page fault, Fiasco will sent a message (an IPC) to the pager thread of that thread. The pager is responsible to handle the page fault to let the thread continue execution. A likely way to resolve a page fault is to map memory at the page fault location. That one who's mapping the memory must, of course, have this memory. And the pager itself can also cause page faults which need to be handled. In the end, sigma0 is the first pager in the system as it has all memory. It does not mean that sigma0 handles every page fault in the system, quite the contrary.
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.
Yes.
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.
It's nothing about forcing anything, it's just how things work. Any task can map out memory it has itself, and a thread in a task can receive page-faults, thus they can resolve page-faults by mapping memory to this other task. This functionality provided by the kernel, so no other L4Re component required. I unsure what you're exactly looking for, but the page-fault handling is implemented in arch/l4/kernel/dispatch.c in L4Linux. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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
Hi, On Thu Jul 23, 2015 at 17:32:47 +0200, Mahdi Aichouch wrote:
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?
You mean accessing as in looking/touching the data therein? No, it doesn't do that. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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@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
Hi, On Fri Jul 24, 2015 at 09:12:27 +0200, Mahdi Aichouch wrote:
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.
Fiasco never accesses any user memory, so no, it doesn't. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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@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@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 > > > > >
Hi, On Tue Jul 28, 2015 at 16:10:04 +0200, Mahdi Aichouch wrote:
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?
We use UTCBs for that. A UTCB is a dedicated memory region that each thread has. Threads copy their IPC payload into their UTCB and the kernel then copies the content to the receiver's UTCB. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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@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@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@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 >> >> >> >> >> >
Hi, On Fri Jul 31, 2015 at 17:03:48 +0200, Mahdi Aichouch wrote:
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.
Getting the physical address of the UTCBs is not possible. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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@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@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@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@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 >>> >>> >>> >>> >>> >> >
Hi, On Wed Sep 09, 2015 at 15:28:24 +0200, Mahdi Aichouch wrote:
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.
Concerning the virtual memories of the tasks, the L4Linux kernel is not visible there but Fiasco as with L4Linux's VM, and as with any task. Also, for the L4Linux VM, I'd say 0, 1, 3, and 4 should also be accounted to L4Linux because all the memory a L4Linux task has comes from memory of the L4Linux kernel (they share the memory). Same for the physical memory display. For an abstract view the mapping of virtual to physical pages seems to be ok. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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@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@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@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@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@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 >>>> >>>> >>>> >>>> >>>> >>> >> >
Hi, On Wed Sep 16, 2015 at 11:45:06 +0200, Mahdi Aichouch wrote:
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.
Looks ok. The upper middle box should also carry the L4Linux task colors because the L4Linux kernel also has this memory.
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?
No, the microkernel has nothing to do with allocating pages to tasks, it just offers the mechanisms to do so. The runtime environment does however, and yes, moe, which is providing memory to tasks, provides a copy-on-write mechanism to allocate memory for tasks.
That means, the physical memory region allocated to an L4 task might not be formed by a contiguous set of physical pages.
It is true that the memory pages allocated to a task might not be physically contiguous.
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.
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.
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.
Loading Linux programs is done by the Linux kernel as usual, there's no difference for L4Linux. All the L4-specific memory adaptions are under arch/l4, and you probably want to look at least into lib/pte.c, kernel/dispatch.c and include/asm/generic/memory.h. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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@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@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@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@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@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@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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >
Hi, On Mon Sep 28, 2015 at 10:44:19 +0200, Mahdi Aichouch wrote:
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.
This is an interesting requirement. First what is to consider is that there's a hierarchy of dependencies and that not all of the components can be strictly separated. For example, sigma0 has all memory, so one can make its text, data etc. contiguous but it also needs to give memory to others, i.e. sharing it with them. For anything running on moe you can give each application a specific memory allocator that has exactly the size required. However, in the allocator you'd need to make sure that it's all physically consecutive. For Fiasco, sigma0 and moe you need to check separately whether it already fulfills your needs or not.
Currently the memory allocator is present in moe package, right?
Yes.
Thus, a new memory allocator should to be added to that package I guess, right?
Yes, moe is implementing the allocator and dataspaces for applications. There's no such thing for Fiasco, sigma0 and moe as they actually build up the functionality to have dataspaces.
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.
This is already available via the dataspace interface, given the memory in the dataspace is allocated as 'pinned' (so that is cannot be moved around by the implementor of the dataspace). See L4Re::Dataspace::phys
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.
For sigma0 and moe it is easier because they run identity mapped. In the kernel there is also functionality to convert between virtual and physical addresses, see the Mem_layout class. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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@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@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@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@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@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@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@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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
Hi, On Wed Oct 07, 2015 at 15:42:36 +0200, Mahdi Aichouch wrote:
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?
Exactly.
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.
The loaders just load the binary, i.e. the layout of the binary needs to be according to your requirements. The loaders will not and cannot change how the binary has been built. The layout of binaries is generated according to the linker script used when linking the program. That allows you to generate a layout according to your requirements. The linker script used in L4Re are in pkg/ldscripts, bootstrap uses a specific linker script. What you are looking for are the program headers in the ELF binary, look at them using objdump or readelf. This way you can influence the layout of a binary and possibly pull sections together. However, this is not enough because a stack will also be dynamically allocated by the loader and its location is not defined by the binary. I think here you need to ensure within the loader that they are close to the loaded binary. Remember it's good to have an address space hole below the stack to detect stack overflows. Plus, the memory allocator must supply memory that physically adjacent to the heap. I guess that needs some extension in moe's allocators at least and according usage in libloader where the memory for programs is allocated. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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@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@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@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@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@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@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@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@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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
Hi, On Mon Oct 26, 2015 at 10:24:57 +0100, Mahdi Aichouch wrote:
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?
All memory is physical in the end. UTCBs are allocated by the kernel (on behalf of programs) and are accessible by the kernel and in the user's virtual memory, i.e.: yes. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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@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@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@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@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@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@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@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@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@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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
Hi, On Fri Nov 20, 2015 at 16:00:58 +0100, Mahdi Aichouch wrote:
The UTCB is allocated as a physical memory page, which is a 4KB if a small page is used, right?
The default is 4k, yes.
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?
Yes, possible. Look at the l4_task_add_ku_mem function in l4sys. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
Hi, On Mon Nov 30, 2015 at 15:33:08 +0100, Mahdi Aichouch wrote:
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.
No, that won't happen. However, the kernel part (the upper part) is of course shared in all address spaces.
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.
The drawing is cluttered. Maybe do not use tabs, or just some image format.
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.
It's in the kernel's part, i.e. in those upper 16MB part. Adam
+-------------------------------------------------------------------+ |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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
-- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
Hi, On Fri Dec 11, 2015 at 16:49:06 +0100, Mahdi Aichouch wrote:
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.
In your code, you should check the return values when calling the phys() function. phys() will only work for memory that has been created 'pinned' meaning that this memory can not be moved around. Memory for programs is (typically) not allocated with this attribute and thus phys will not work here. If you just want to know the physical address of a virtual address once, you should do this via jdb: press 's', move cursor to the task in question, press 'p' which gives you the page-table view. In that view you can explore the page table of the task you selected. On the last level you'll see the physical frame number. Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
Hi, On Mon Dec 14, 2015 at 16:47:11 +0100, Mahdi Aichouch wrote:
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");
Yes, use + to combine them.
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.
Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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@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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
Hi, On Mon Jan 04, 2016 at 17:03:49 +0100, Mahdi Aichouch wrote:
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.
Looking more closely at your last mail... the ldr_flags=... needs to go out one level of {}, i.e.: L4.default_loader:start({ ldr_flags = L4.Ldr_flags.eager_map + L4.Ldr_flags.pinned_segs, log = { "hello1", "green" } }, "rom/hello");
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.
Thats ok to do for your use case.
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@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@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.
The L4Linux you are loading via ned is not the Linux kernel but a wrapper around that that contains the Linux kernel. L4Re will load the wrapper while the Linux output is the actual Linux kernel. The output before "=== L4Linux starting ===" is from the loader that is loading/unpacking the inner part, you probably want to look there as well (arch/l4/boot/ldr.c). Adam -- Adam adam@os.inf.tu-dresden.de Lackorzynski http://os.inf.tu-dresden.de/~adam/
participants (2)
-
Adam Lackorzynski -
Mahdi Aichouch