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

Gedare Bloom gedare at rtems.org
Wed May 30 16:32:49 UTC 2012

On Tue, May 29, 2012 at 5: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

This matches the "libmmu" work and is a good way to continue
talking/thinking about the problem.

> - 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.

I tend to agree here. The attributes type can be made into a pointer
type and the arena interface can provide ways to get/set attribute
values on the attribute type.

> - 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.

This is an interesting idea and worth thinking about some more. I can
see the advantage, and I think that if the attribute type is made
opaque and the arena interface provides getters/setters with the BSP
providing the implementation then we can avoid any unnecessary bit
translations. The BSP can provide an efficient means for representing
attributes for the specific HW mechanism being used (e.g. mmu, mpu,

> - 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.

Agreed. Static partitioning of the memory space is a must. Note that
static here would  mean you set up the memory space during boot/init
and possibly an application startup phase, but afterward the context
switch does nothing extra; In the terminology of the arenas this would
be a use case where an application sets up all arenas to be shared by
all tasks, and disables context switching arenas since a context
switch would be unnecessary / redundant.

> - 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.

We could evaluate this cost some more, but right now the memory
overhead is just a chain_control per arena to represent tasks. I'm not
sure that reducing this overhead to one pointer (rather than two) is
such a big deal.

> - Always minimize overhead, whether in memory or cache footprint, CPU cycles, or whatever.

Agreed. We should be sure to minimize the costs incurred when not
using these mechanisms too. I see three general schemes: no arena,
static arena, full arena.

> - 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.

Yes we have been working to keep the interface namespace clean. The
general rule of thumb for internal RTEMS code is to use functions with
_Package_name_Method_name. For user-exposed APIs it is
rtems_package_name_method_name. Types omit the leading underscore.
Somewhere out there (beneath the pale moonlight) someone has a style
guide codifying these issues. We should work to get it pushed out to
the developer community...

> - 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.

Part of the problem is that MMU may be too specific. Not all memory
management uses an "MMU" so we should be careful about being overly
restrictive as well. I too have my doubts about the name Arena, but I
think that driving a user-API focusing on both MMU control and, later,
memory allocation can provide a useful way to keep thinking about this
memory management problem in a general sense.  I had originally
started with Memory_protection but that too is overly specific since
many of the memory attributes are not strictly for "protection".
Naming is always hard.

> If I was too brief above, ask questions.
>        Ric
Thanks for the feedback

> 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
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel

More information about the devel mailing list