[okl4-developer] About the virtual memory management of OKL4

[kashin Lin]

Hi,

thanks for your reply, i got more clear about that.

i still have some quetions:

as you mentioned last time :" Any other address spaces have their mappings
initialised by the
root task itself", are those mappings for "RAM memory
space"  only? because i noticed that some
codes (like driver) call "hardware_back_memsection(memory, PHY_BASE,
L4_IOMemory)" first
before they can access those "IO memory space".

if i write a l4 application (ex: in
okl4_src/iguana/example/), which wants to access DSP memory.
should i call "hardware_back_memsection" first ? for example:
                uint32_t dsp_virt;
                uintptr_t dsp_obj;

                dsp_obj = memsection_create_user(0x1000, &dsp_virt);
                hardware_back_memsection(dsp_obj, DSP_BASE, L4_IOMemory);

                and use **(dsp_virt + offset) to access DSP?
or i can just use *DSP_BASE to access it?

thanks in advance.


best regards,

kashin lin


2007/11/21, Ben Leslie <benno at ok-labs.com>:
>
> On Sat Nov 17, 2007 at 18:19:52 +0800, kashin Lin wrote:
> >Hi,
> >
> >i have read okl4-progmanual & iguana-usermanual, but confused their
> memory
> >management.
> >
> >in l4 microkernel, threads in the same address space belong to the same
> >process(task). so it means
> >there will be various address
> >space. but with iguana, all threads belong to the same process(task) are
> >in the same
> >address space with different PD. all thread created by iguana are also
> >l4 threads ,
> >why those difference exist?
>
> How the microkernel and the root task relate is a confusing point of
> L4.
>
> The root task, in this case Iguana, is free to present its own
> abstraction to user programs. It uses the underlying microkernel to
> implement those abstractions.
>
> In this case, each Iguana protection domain is implemented by an
> underlying L4 address space.
>
> It happens that Iguana ensures that all these L4 address spaces have
> the same virtual -> physical mapping. (Although they do have different
> permissions on the virtual memory.)
>
>
> >in l4 microkernel, threads can communicatin between different or same  AS
> by
> >l4_IPC. but
> >according to iguana manual, why it says "Explicit L4 mapping IPC is not
> >permitted between Iguana
> >protection domains". threads created with iguana are in the same AS,
> aren't
> >they?
>
> This is a case of the usermanuals being slightly out of date. Older
> versions of the L4 API allowed memory to be mapped between L4 address
> space by sending a "mapping IPC". To ensure the single-address-space
> model is preserved, Iguana did not allow this operation to occur.
>
> The latest versions of L4 do not have this feature any more, so the
> comment
> in the Iguana manual is redundant.
>
> >if i created a thread, what's are the address space it can access (PHY
> >addr)?
> >either creating a thread "directly on L4" or "with iguana", will the
> >PHY address
> >it can access be different?
>
> In L4 the only way to create a thread is have the root-task create it.
> So, if you are using Iguana, only Iguana is allowed to directly create
> a thread. Any other programs that wish to create threads must ask
> Iguana to do this on their behalf.
>
> >(in okl4-progmanual, it says "This address space is initialised at boot
> time
> >by the microkernel based
> >on the initial mapping descriptors in the KIP memory descriptors as
> >described in Chapter B-5."
> >but it's missing)
>
> This refers to the address initial root task address space. Any other
> address spaces have their mappings initialised by the root task itself.
>
> >maybe these quetions due
> >to my less comprehend of the relationship between l4 & iguana.
> >so it will be better if you can show me that.
> >
> >i really need to comprehend those. any help will be welcome!
> >thanks in advance~
>
> Hopefully this has helped explain things, but maybe not. If not please
> feel free to write again, and I will try to clarify any points.
>
> Cheers,
>
> Benno
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okl4.org/pipermail/developer/attachments/20071125/22763542/attachment.htm