Question about memory management in L4 Fiasco O.C + L4re
Adam Lackorzynski
adam at os.inf.tu-dresden.de
Thu Dec 3 00:10:34 CET 2015
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 at gmail.com> wrote:
>
> > Hello Adam,
> >
> > The UTCB is allocated as a physical memory page, which is a 4KB if a small
> > page is used, right?
> >
> > Do you think that it is possible to allocated a 16KB or 32KB UTCB area,
> > and to align their physical start address on 16KB or 32KB?
> >
> > Thank you in advance for your answer.
> >
> > Best regards,
> >
> > Mahdi
> >
> >
> > On Mon, Oct 26, 2015 at 10:24 AM, Mahdi Aichouch <foxmehdi at gmail.com>
> > wrote:
> >
> >> Hello Adam,
> >>
> >> I have a question about the UTCB area.
> >> If I understand correctly, the UTCB is physical memory page that is
> >> allocated in the kernel physical memory space, then mapped into the user
> >> and kernel virtual memory space, right?
> >>
> >> Thank you very much for your answer.
> >>
> >> Best regards,
> >> Mahdi
> >>
> >>
> >> On Wed, Oct 7, 2015 at 3:42 PM, Mahdi Aichouch <foxmehdi at gmail.com>
> >> wrote:
> >>
> >>> Hello Adam,
> >>>
> >>> In order to be sure that I correctly understand how Dataspace and Memory
> >>> Allocator work, I tried an example where Dataspace are created using the
> >>> "L4Re::Mem_alloc::Continuous and L4Re::Mem_alloc::Pinned" flags. This will
> >>> ensure that the allocated physical memory is contiguous and can not be
> >>> moved, right?
> >>>
> >>> My second question concerns the way how an L4 task is loaded into
> >>> memory. Do you think that it is possible to make all segments of an L4 user
> >>> program to be adjacent in physical memory. As an example, given one L4 user
> >>> program we would like to have the following configuration:
> >>>
> >>> Physical memory
> >>>
> >>> 0x000000 0MB
> >>>
> >>> 0x100000 1MB
> >>> text
> >>> 0x200000 2MB
> >>> data
> >>> 0x300000 3MB
> >>> stack
> >>> 0x400000 4MB
> >>> heap
> >>> 0x500000 5MB
> >>>
> >>> (the memory addresses are given here for illustration purpose)
> >>>
> >>> From my tracing of Moe, L4re and libloader using Moe::Dataspace::phys( )
> >>> function, I saw that some areas were adjacent and other were not. Could
> >>> you please give an explanation of how Moe and l4re load a user program from
> >>> a disk into memory.
> >>>
> >>> Thank you very much in advance.
> >>>
> >>> kind regards,
> >>> Mahdi
> >>>
> >>>
> >>> On Mon, Sep 28, 2015 at 10:44 AM, Mahdi Aichouch <foxmehdi at gmail.com>
> >>> wrote:
> >>>
> >>>> Hello Adam,
> >>>>
> >>>> > An application is typically composed of multiple memory regions in
> >>>> > virtual memory. Do you mean you want all those regions to be physically
> >>>> > contiguous, such as text-segment, bss and stacks? This should be
> >>>> > possible by using a memory allocator that makes sure this is the case.
> >>>> > However, currently, there is only the possibility to have dataspaces
> >>>> > physicall contiguous.
> >>>>
> >>>> This exactly what I mean, that is, text-segment, bss, data, stack, and
> >>>> heap regions have to be contiguously allocated for Fiasco kernel, sigma0,
> >>>> moe, L4Linux, and for each created L4 task.
> >>>> My use case requires that each created L4 task has to be provided with
> >>>> a static fixed physical memory segment, and cannot exceed its allocated
> >>>> memory segment.
> >>>>
> >>>> Currently the memory allocator is present in moe package, right?
> >>>> Thus, a new memory allocator should to be added to that package I
> >>>> guess, right?
> >>>> If not, could you please suggest a place in the code base where a new
> >>>> memory allocator has to be added.
> >>>>
> >>>> I would like to implement a mechanism that allow to know for each
> >>>> created L4 task which physical frame a virtual page is mapped to. The
> >>>> functionality provided by such a service are similar to
> >>>> pagemap [1] service in Linux kernel.
> >>>>
> >>>> Is such a service could be implemented at userspace in L4re?
> >>>> Does Fiasco O.C provide the necessary mechanism to implement it?
> >>>> If yes, could you please suggest a set functions that should be used.
> >>>>
> >>>> Thank you very much for your answer.
> >>>> Best regards,
> >>>>
> >>>> Mahdi
> >>>>
> >>>> [1] https://www.kernel.org/doc/Documentation/vm/pagemap.txt
> >>>>
> >>>> On Wed, Sep 16, 2015 at 11:45 AM, Mahdi Aichouch <foxmehdi at gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hello Adam,
> >>>>>
> >>>>> I updated the schema of the memory mapping of L4Linux and Fiasco O.C
> >>>>> according to your corrections.
> >>>>> Could you please take a look at it and tell me if everything is
> >>>>> correct.
> >>>>>
> >>>>> I have some questions about the way Fiasco O.C µ-kernel loads the L4
> >>>>> tasks into physical memory.
> >>>>>
> >>>>> If I correctly understood, when Fiasco O.C creates a new L4 task it
> >>>>> uses a copy-on-write
> >>>>> mechanism to allocate physical pages in memory, right?
> >>>>> That means, the physical memory region allocated to an L4 task might
> >>>>> not be formed
> >>>>> by a contiguous set of physical pages.
> >>>>>
> >>>>> Is it possible to make Fiasco O.C reserves a physical memory region
> >>>>> composed by a
> >>>>> set of contiguous physical memory pages when creating an L4 task?
> >>>>>
> >>>>> If the answer is yes, could you please suggest an example showing the
> >>>>> way to do it.
> >>>>>
> >>>>> My second question concerns the L4Linux tasks. Could you please tell
> >>>>> me some
> >>>>> explanation about the way L4Linux and Fiasco O.C load into physical
> >>>>> memory the L4Linux tasks,
> >>>>> and where can I find the code that is doing these operations.
> >>>>>
> >>>>> Thank you very much in advance.
> >>>>>
> >>>>> Best regards,
> >>>>>
> >>>>> Mahdi
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Sep 9, 2015 at 3:28 PM, Mahdi Aichouch <foxmehdi at gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Hello Adam,
> >>>>>>
> >>>>>> In order to document my investigation of memory management in L4Linux,
> >>>>>> I draw an abstract representation of the memory mapping of L4Linux's
> >>>>>> tasks
> >>>>>> virtual memory into L4Linux "real" memory and into physical memory.
> >>>>>>
> >>>>>> Could you please take a look at my schema and tell if it correctly
> >>>>>> represents
> >>>>>> the memory mapping in L4Linux.
> >>>>>>
> >>>>>> Any corrections and remarks are welcome.
> >>>>>>
> >>>>>> Thank you very much in advance.
> >>>>>>
> >>>>>> Best regards,
> >>>>>>
> >>>>>> Mahdi
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jul 31, 2015 at 5:03 PM, Mahdi Aichouch <foxmehdi at gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hello Adam,
> >>>>>>>
> >>>>>>> Is it possible to know where a UTCB memory area is allocated in the
> >>>>>>> physical memory space of a thread.
> >>>>>>> If the answer is yes, could you please suggest a way to do it.
> >>>>>>>
> >>>>>>> Thank you very much for your answer.
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> Mahdi
> >>>>>>>
> >>>>>>> On Tue, Jul 28, 2015 at 4:10 PM, Mahdi Aichouch <foxmehdi at gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hello Adam,
> >>>>>>>>
> >>>>>>>> I have a question about the way Fiasco.OC handles IPC.
> >>>>>>>>
> >>>>>>>> If we take a simple example of one thread in address space A that
> >>>>>>>> sends an array of characters to a second
> >>>>>>>> thread located in an address space B.
> >>>>>>>> Since such an array might be large and cannot be transferred using
> >>>>>>>> the registers.
> >>>>>>>>
> >>>>>>>> How it is transferred to the second thread address space?
> >>>>>>>>
> >>>>>>>> Is it at first allocated on the first thread stack, then copied by
> >>>>>>>> Fiasco kernel to
> >>>>>>>> the second thread address space?
> >>>>>>>>
> >>>>>>>> Thank you very much for your answer.
> >>>>>>>>
> >>>>>>>> Best regards,
> >>>>>>>> Mahdi
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Fri, Jul 24, 2015 at 9:12 AM, Mahdi Aichouch <foxmehdi at gmail.com
> >>>>>>>> > wrote:
> >>>>>>>>
> >>>>>>>>> Hello Adam,
> >>>>>>>>>
> >>>>>>>>> What I mean by accessing memory partition is: does Fiasco.OC
> >>>>>>>>> accesses memory
> >>>>>>>>> reserved for L4Linux when handling system-call issued by L4Linux
> >>>>>>>>> guest for example
> >>>>>>>>> or any other operation.
> >>>>>>>>>
> >>>>>>>>> Thank you very much for your answer.
> >>>>>>>>>
> >>>>>>>>> Best regards,
> >>>>>>>>> Mahdi
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Thu, Jul 23, 2015 at 5:32 PM, Mahdi Aichouch <
> >>>>>>>>> foxmehdi at gmail.com> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hello Adam,
> >>>>>>>>>>
> >>>>>>>>>> I would like to know if Fiasco.OC kernel accesses memory
> >>>>>>>>>> partition allocated to an L4Linux guest?
> >>>>>>>>>> And for what reasons it has to do it?
> >>>>>>>>>>
> >>>>>>>>>> Thank you very much for your answer.
> >>>>>>>>>>
> >>>>>>>>>> Best regards,
> >>>>>>>>>> Mahdi
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Jul 22, 2015 at 3:19 PM, Mahdi Aichouch <
> >>>>>>>>>> foxmehdi at gmail.com> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hello Adam,
> >>>>>>>>>>>
> >>>>>>>>>>> According to Fiasco O.C/L4re documentation Sigma0 is the root
> >>>>>>>>>>> pager,
> >>>>>>>>>>> that is, it is responsible of resolving page fault of user-level
> >>>>>>>>>>> tasks, right?
> >>>>>>>>>>>
> >>>>>>>>>>> Knowing that L4Linux is created as a user-level task, thus any
> >>>>>>>>>>> memory page fault occurring
> >>>>>>>>>>> in L4Linux or its user processes logically has to be handled
> >>>>>>>>>>> through Sigma0.
> >>>>>>>>>>>
> >>>>>>>>>>> However, as you previously mentioned in one of your answers, a
> >>>>>>>>>>> handling of
> >>>>>>>>>>> a page fault occurring in L4Linux does not involve any L4Re
> >>>>>>>>>>> object including Sigma0.
> >>>>>>>>>>>
> >>>>>>>>>>> My question is: what configuration and / or operations have been
> >>>>>>>>>>> made
> >>>>>>>>>>> in order to force that a memory page fault in L4Linux has to be
> >>>>>>>>>>> handled
> >>>>>>>>>>> only by Fiasco and L4Linux and not going through L4Re objects?
> >>>>>>>>>>> And where these operations are written in the source code.
> >>>>>>>>>>>
> >>>>>>>>>>> Thank you very much for your answer.
> >>>>>>>>>>>
> >>>>>>>>>>> Best regards.
> >>>>>>>>>>> Mahdi
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Jul 21, 2015 at 4:06 PM, Mahdi Aichouch <
> >>>>>>>>>>> foxmehdi at gmail.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hello Adam,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would like to understand how L4 Fiasco manages the virtual
> >>>>>>>>>>>> memory of a L4Linux guest.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Does L4 Fiasco maintains a "shadow page table" in order to
> >>>>>>>>>>>> perform a two-level memory address translation:
> >>>>>>>>>>>> guest virtual memory --> guest real memory --> host physical
> >>>>>>>>>>>> memory?
> >>>>>>>>>>>>
> >>>>>>>>>>>> If the answer is yes, where the "shadow page table" is
> >>>>>>>>>>>> maintained? which L4 Fiasco object
> >>>>>>>>>>>> is responsible of this operation?
> >>>>>>>>>>>>
> >>>>>>>>>>>> If we suppose that an L4Linux guest has for example a 64MB of
> >>>>>>>>>>>> fixed physical memory region,
> >>>>>>>>>>>> in case a new L4Linux user task arrives and there is no
> >>>>>>>>>>>> available space to allocate
> >>>>>>>>>>>> a new page for this task, an already used page has to be
> >>>>>>>>>>>> unmapped, right?
> >>>>>>>>>>>>
> >>>>>>>>>>>> If the answer is yes, then where the dirty page will be swapped?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thank you very much for your answer.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Best regards,
> >>>>>>>>>>>> Mahdi
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Mon, Jul 20, 2015 at 4:36 PM, Mahdi Aichouch <
> >>>>>>>>>>>> foxmehdi at gmail.com> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Hello Adam,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If I correctly understood, and If we suppose that an L4Linux
> >>>>>>>>>>>>> instance
> >>>>>>>>>>>>> is started for example with this command line options:
> >>>>>>>>>>>>> ... earlyprintk=1 em=64M ...
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This means that a 64MB of physical memory region composed of a
> >>>>>>>>>>>>> set of contiguous physical frames is allocated to L4Linux, right?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> L4Linux will use a part of this 64MB of physical memrory for
> >>>>>>>>>>>>> its own kernel execution, and
> >>>>>>>>>>>>> the rest of physical memory space will be used by L4Linux to
> >>>>>>>>>>>>> load user-level programs
> >>>>>>>>>>>>> and allocate physical memory for them, right?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If a user-level program on top of L4Linux generates a
> >>>>>>>>>>>>> page-fault.
> >>>>>>>>>>>>> Are the L4 Fiasco kernel and L4re involved in the execution
> >>>>>>>>>>>>> flow to handle the page-fault?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thank you very much for your clarification.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Mahdi
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Fri, Jul 17, 2015 at 10:36 AM, Mahdi Aichouch <
> >>>>>>>>>>>>> foxmehdi at gmail.com> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hello Adam,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The memory regions are exclusive. Specifying exactly which physical
> >>>>>>>>>>>>>>> memory an L4Linux is getting is currently not possible but I guess
> >>>>>>>>>>>>>>> you're using the numbers just as an example?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Yes, I am giving these numbers as an example.
> >>>>>>>>>>>>>> However, is it possible to know what are the start address and the end address
> >>>>>>>>>>>>>> of a physical memory partition allocated to a L4Linux instance?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The memory is completely mapped initially, so no page fault should
> >>>>>>>>>>>>>>> happen. As probably nobody will take it away again it should also stay
> >>>>>>>>>>>>>>> like this.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Does this apply also to user-level programs executed on top of L4Linux.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> You can put showpfexc=1 on the cmdline to see any in-kernel page fault.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>> There shouldn't be any (except in the outside wrapper code as I see
> >>>>>>>>>>>>>>> which can be changed by launching L4Linux with the eager_map flag).
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Could please give some explanation about what is the wrapper code? And Where to set the "eager_map flag" option?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thank you very much for your answer!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Mahdi
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Jul 15, 2015 at 11:53 AM, Mahdi Aichouch <
> >>>>>>>>>>>>>> foxmehdi at gmail.com> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Hello,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I have some questions concerning memory management in Fiasco
> >>>>>>>>>>>>>>> O.C + L4re.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I would like to test two L4Linux instances, and for each
> >>>>>>>>>>>>>>> L4Linux
> >>>>>>>>>>>>>>> instance I want to reserve one static fixed physical memory
> >>>>>>>>>>>>>>> partition.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> For instance, one 128MB for the first L4Linux and one 128MB
> >>>>>>>>>>>>>>> for the second.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Knowing that Fiasco O.C. uses "on demand paging" to allocate
> >>>>>>>>>>>>>>> pages for
> >>>>>>>>>>>>>>> user tasks, is it possible that each partition of L4Linux
> >>>>>>>>>>>>>>> could be allocated
> >>>>>>>>>>>>>>> a static physical memory region composed of contiguous
> >>>>>>>>>>>>>>> physical frames.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> For instance, one memory region starting from 128MB to 256MB
> >>>>>>>>>>>>>>> for the first L4Linux,
> >>>>>>>>>>>>>>> and second memory region from 256MB to 512MB for the second
> >>>>>>>>>>>>>>> L4Linux.
> >>>>>>>>>>>>>>> Each memory region is allocated exclusively to one L4Linux
> >>>>>>>>>>>>>>> instance.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I would like to know if it is possible to load all the code
> >>>>>>>>>>>>>>> + data of a L4Linux instance
> >>>>>>>>>>>>>>> into its reserved memory partition, so no page fault will be
> >>>>>>>>>>>>>>> encountered during runtime.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Is it possible to tell me if these above operations could be
> >>>>>>>>>>>>>>> realized in Fiasco O.C and L4re?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> If the answer is yes, is it possible to tell me what are the
> >>>>>>>>>>>>>>> objects that should be used or
> >>>>>>>>>>>>>>> adapted in order to implement these?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> What are the issues that I should pay attention to?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Many thanks in advance for your answer.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Best regards,
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Mahdi
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
--
Adam adam at os.inf.tu-dresden.de
Lackorzynski http://os.inf.tu-dresden.de/~adam/
More information about the l4-hackers
mailing list