[GSoC2012] RTEMS MMU/MPU support for ARM architecture project ( High-level design )

[Hesham Moustafa]

I think the three layers you suggested map to other three layers in my
proposal which are a high-level layer ( application layer ), mid-level
layer ( OS layer ) and a low-level layer ( BSP layer ). kindly you can
check all the details in my project proposal [1]. libarena.h file is the
API for application layer only.

About ARENA_ATTRIBUTES , it's just a way for the application layer to
determine which attributes must be enforced at the low-level layer (MMU in
our case). Otherwise, how can the application layer tells OS/BSP layer
about the attributes it needs ?

RTEMS provides a heap allocator, that's why it's not always "static". So
Arena is just a feature can be used by the user if needed at configuration
stage before building the system. But I will consider providing support for
static MMU use.

There are also a previous projects dealing with MMU context which i rely on
[2]. So Arena is just a way to provide memory management and Arena
allocation is a future work of my project.

Thanks for you feedback.

[1]
https://docs.google.com/document/d/14ZpL07pBsbQAGGhClL48Fr3jWHFM-kp3WxIi0kBdQy0/edit
[2] http://code.google.com/p/gsoc2011-rtems-mmu-support-project/

On Tue, May 29, 2012 at 11:22 PM, Claus, Ric <claus at slac.stanford.edu>wrote:

> A few suggestions:
>
> - This is a generic problem.  Try to keep  the ARM in the back of your
> mind as a test use case instead of the driving factor.
> - Break the problem up into (at least) three layers:
>  1) The API presented to the BSP writer
>  2) The API presented to the OS
>  3) The API presented to the application
> - Don't presume that the 'attributes' can all fit into a 32 bit quantity.
>  Better to make it a structure that is presented by the BSP, and known to
> the application, but opaque to the OS.  If the OS needs access to certain
> attributes, then ones common across all target architectures should be
> distilled out and accessed through a separate interface.
> - In your more recent e-mail about libarena.h, I suggest that the
> ARENA_ATTRIBUTES bit masks should be owned by the BSP, not the OS.  You
> want to avoid translating one set of bit masks into another in order to
> keep overhead down, and only the BSP can know how the particular MMU
> implementation defines the attributes.
> - In general, there is no reason to presume that memory management has
> anything to do with tasking. Certainly in some cases it is a useful idea to
> swap memory attributes with context switches, but by no means in all.
>  Since RTEMS is an RTOS, probably the majority of its users will want to
> statically set up their memory environment (read-only code sections,
> non-cacheable IO sections, etc.) and avoid as much of the overhead
> associated with context switching as they can.  Perhaps there should be a
> task attribute that says whether context switching should involve the MMU
> or not, like the situation with floating point support.  In any case,
> consider providing support for static MMU use.
> - Use an encapsulating structure to hold the tasking related information
> (e.g. links, etc.) so that users of the static interface don't have to pay
> the overhead of, to them, useless information.  In other words, consider a
> 2 layered approach wherein the tasking related implementation depends on
> the static interface.
> - Always minimize overhead, whether in memory or cache footprint, CPU
> cycles, or whatever.
> - Try to avoid encroaching on other peoples' namespace.  Not sure whether
> RTEMS has rules about such things, but it certainly has a pattern to follow.
> - Personally, I dislike using a generic name (Arena) for a specific
> concept (memory management).  It would make more sense to me to talk about
> MMU_regions or MMU_zones or suchlike, and leave Arena to mean an allocator
> of chunks of memory within a generic block of memory, which could be such a
> region or zone.
>
> If I was too brief above, ask questions.
>
>        Ric
>
>
> On May 24, 2012, at 2:27 PM, Hesham Moustafa wrote:
>
> >
> > This is introduction to my project design , I would appreciate any
> feedback.
> >
> > Introduction to Arena :
> >
> >
> > The main problem we want to solve is how to make it easier for users to
> apply memory protection attributes in a flexible way. Developer who want to
> control this area of memory and apply/modify or even delete memory
> protection attributes should make use of libmmu [1] (the result of previous
> GSoC2009/2011 projects that provide memory protection through mmu). But
> developer has to know how to work with this API and some low-level
> knowledge about how the core implements memory protection. To satisfy the
> need for usable memory protection, I am introducing arenas, which control
> memory protection attributes of an area of memory. Arena only has the start
> address and size of an area of memory and needed memory protection
> attributes to be applied on this area. No libmmu or low-level knowledge is
> required by a developer who uses Arena to apply memory protection, only the
> memory area description and memory protection attributes.
> >
> > Arena could be created by a developer by passing the chunk of memory
> that needs to have memory protection attributes. Arena can support sharing
> if there is an area of memory that a developer wants to share between many
> tasks with the same access attributes (i.e code segment ). Arena could be
> defined as a construct which specifies memory attributes that could be
> shared among tasks.
> >
> > Arenas and tasks have a many-to-many symmetric relationship. All tasks
> having access to an Arena are "attached" to that Arena. Also a set of
> Arenas that a specific task has access to are said to be its "Attached
> Arenas". Context switch code deactivates all Arenas the current task is
> attached to, and activates the next task’s attached Arenas therefore the CS
> code needs a way to access all of the arenas attached to a given task.
> Representing attached Arenas for a task in a linked list/array to keep
> track of relationship between a task and its attached Arenas is useful so
> that a context switch code can know which Arenas to deactivate by just have
> a pointer to current task’s attached Arenas list in its TCB and walk
> through it to deactivate all the list. When Arena is deleted, all attached
> tasks TCBs must be updated by deleting this Arena from their lists. The
> process of updating TCBs could be done by representing attached tasks in a
> linked list of pointers to TCBs in the ACB, So when an Arena is deleted it
> traverses the list and updates each attached task’s TCB.
> >
> > Further (optional) goal is to embed an allocator to an Arena which could
> be. Then an Arena could be used to allocate memory from its pool, providing
> tasks a way to share and divide protected memory regions efficiently.
> Another further goal is to provide Posix mmap support and implementing it
> using arenas. Also i consider adding naming capability to an Arena.
> >
> > [1] : http://code.google.com/p/gsoc2011-rtems-mmu-support-project/
> >
> > Proposed Interfaces :
> >
> >
> > struct Arena_Control {
> >   Objects_Control  Object;
> >   /* starting address of the arena’s memory pool */
> >   void         *start_address ;
> >   /* size of the arena’s memory pool */
> >   size_t       size ;
> >   /* memory attributes like w/r/x, cacheable */
> >   uint32_t    attributes;
> >
> >   /* linked list of tasks that are attached to this arena. Points to
> >    * an Arena_Per_task structure embedded in a Thread_Control. */
> >   Chain_Control     attached_tasks;
> > }
> >
> > // The TCB would have a pointer to an array of the following struct.
> > struct Arena_Per_task {
> >   /* node of the task in attached_arena->attached_tasks list */
> >   Chain_Node node;
> >   /* pointer to a specific Arena which this task is attached to. */
> >   Arena_Control *attached_arena;
> > }
> >
> > struct Thread_Control {
> >   …
> >   /* array of Arena_Per_task of fixed maximum size. NULL if arenas are
> not used. */
> >   Arena_Per_task *attached_tasks;
> >   …
> > }
> >
> >
> >   Arena_Status _Arena_Initialize( ) ;
> >
> > /* This function will apply setup fields in Arena_Control and apply
> memory protection
> > attributes using libmmu API. Also initializing an empty list of
> attached_tasks. */
> > Arena_Control* _Arena_Create(void* start_address , size_t size , uint32
> attributes ) ;
> >
> >
> > /* This function returns attributes of a given Arena  */
> >  uint32_t  _Arena_Get_attributes (Arena_Control*);
> >
> > /* This function returns the starting address of that Arena in memory
> >  void* _Arena_Get_start_address (Arena_Control* Arena) ;
> >
> > /* This function returns the size of the Arena
> >  size_t _Arena_Get_size (Arena_Control* Arena);
> >
> > /* This function update the current attributes for an Arena with
> new_attributes , could be used for deleting protection */
> >  Arena_Status _Arena_Update_attributes(Arena_Control* , uint32_t
> new_attributes) ;
> >
> > /* This function create a link between an Arena and a task by adding a
> pointer to ACB in TCB’s attached arenas list and By adding a pointer to TCB
> in ACB by adding a pointer to attached task list */
> >  Arena_Status _Arena_Attach(Arena_Control* , Thread_Control*  task);
> >
> > /* This function cut the link between a given Arena one of its attached
> tasks */
> >  Arena_Status _Arena_Detach(Arena_Control* , Thread_Control* task);
> >
> > /* This function mark an Arena as Deactivated when the current task use
> it and a context switch happens, so that the next task can not access this
> deactivated Arena. */
> >  Arena_Status _Arena_Deactivate(Arena_Control*) ;
> >
> > /* This function mark an Arena as Activated when a context switch
> happens, and the next task is attached to that Arena */
> >  Arena_Status _Arena_Activate(Arena_Control*);
> >
> > /* This function delete the Arena and update the Arena list in every
> attached task TCB by deleting the ACB entry of the deleted Arena */
> > Arena_Status _Arena_Delete(Arena_Control* );
> > _______________________________________________
> > rtems-devel mailing list
> > rtems-devel at rtems.org
> > http://www.rtems.org/mailman/listinfo/rtems-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20120530/5481397c/attachment-0001.html>