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

[Hesham Moustafa]

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* );
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20120525/6188a543/attachment-0001.html>