SMP/MMU updating page tables on realview BSP
Hesham Moustafa
heshamelmatary at gmail.com
Fri Jul 5 16:45:55 UTC 2013
On Fri, Jul 5, 2013 at 6:30 PM, Gedare Bloom <gedare at rtems.org> wrote:
> On Fri, Jul 5, 2013 at 12:11 PM, Hesham Moustafa
> <heshamelmatary at gmail.com> wrote:
> > Hi,
> >
> > I am working on a use case for cortex-a9/realview BSP that deals with
> page
> > tables and MMU. I need your help in gathering the required API and calls
> and
> > any other details to implement the following case (if applicable) :
> >
> > 1- A thread running on a core that updates the page table.
> > 2- On another core another thread is running and trying to update the
> page
> > table.
> >
> > Is that use case possible, or disabling dispatches, MMU, and interrupts
> > avoids that situation ?
> >
> I think this is a possible situation. I suppose right now the page
> tables are statically initialized by a boot processor, but if you
> enable dynamically modifying the page table, then you need to protect
> that memory somehow. Probably with a spin lock.
>
> Yes, the page table entries are statically initialized to Zero (fault
sections) at boot
time and then apply attributes and mapping through a config table at boot
time too.
There is a NORMAL_SHARE attribute that can be applied
to a memory region in Cortex-a9 platform that enables the HW to achieve
consistency
for that area of memory. I do not know whether applying that attribute is
enough or we
have to use some locks.
> Is it possible to force a thread to run on a specific core ? or the
> current
> > SMP scheduler handles that ?
> >
> > I am thinking of applying a SHARED_MEMORY attribute on page tables itself
> > and implement the mentioned use case.
> >
> > Regards,
> > Hesham
> >
> > _______________________________________________
> > 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/20130705/6c12d341/attachment-0001.html>
More information about the devel
mailing list