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

[Claus, Ric]

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