Project for GSoC 2020

[Utkarsh Rai]

Thanks for the feedback, I will proceed by keeping MPU implementation in
mind for my proposal.

On Sun, Mar 15, 2020 at 5:21 AM Gedare Bloom <gedare at rtems.org> wrote:

> On Sat, Mar 14, 2020 at 4:07 PM <dufault at hda.com> wrote:
> >
> >
> >
> > > On Mar 14, 2020, at 14:22 , Gedare Bloom <gedare at rtems.org> wrote:
> > >
> > > Hi Utkarsh,
> > >
> > > On Sat, Mar 14, 2020 at 12:05 PM Utkarsh Rai <utkarsh.rai60 at gmail.com>
> wrote:
> > >>
> > >> I am in the middle of drafting the proposal for the memory protection
> project and specifying the interface, one of the things I would like to
> take to your feedback on is what are the functionalities that would be
> provided to the users, as some of the architectures provide a lot of
> support that others don't, should we keep that to a minimum or go with the
> maximum options. For example, ARM provides 4kb, 16kb, and 64kb page
> granules whereas others don't so either the users can be provided with the
> option of accessing other stacks in granules of various sizes or a
> common-minimum of 4kb.
> > >>
> > >> Also, it would be very kind of you if you could help me with the
> previous message on this thread.
> > >>
> > >> On Wed, Mar 11, 2020 at 8:34 AM Utkarsh Rai <utkarsh.rai60 at gmail.com>
> wrote:
> > >>>
> > >>> Before specifying the interface I want to take your kind feedback on
> what all things would need to be done in the interface.
> > >>>
> > >>> By looking into the MMU description of ARM and x86, according to me,
> the implementation would have to be done in two levels-
> > >>>
> > >>> 1. The architecture-specific part, wherein I will have to initialize
> the MMU(already implemented for ARM), TLB management and exception handling.
> > >
> > > Yes. This is done simply in a few ports where needed, usually just to
> > > setup a 1:1 VA-PA mapping.
> > >
> > >>> 2. The generalization part, wherein I will need to manage the thread
> stacks, their access permissions. Each stack should have a data structure
> associated with it that has the permission flags, starting address and
> other relevant information. For increased robustness of the thread stacks,
> every time a context switch takes place we will have to set up the page
> tables, TLBs to map the address of the executing thread as well as that of
> the threads it has the permission to access.
> > >>>
> > >
> > > I think Peter's advice is sound. We have a rough version of mmap
> > > implemented. It has a few problems and isn't completely functional for
> > > all use cases. The main question to consider as we move forward is
> > > whether to allow n:1 VA-PA mappings, which implies a non-linear
> > > address space. I think you will need to do some research about that
> > > topic. I don't think it is a great idea though, since AFAIK it
> > > requires an MMU to implement such mappings so if there is just an MPU
> > > then things may break (or work in weird ways).
> > >
> > >
> >
> > The decision about memory protection unit versus memory management unit
> is essential to decide how this should proceed.  I believe we should
> require only an MPU, a lot of the discussion would require an MMU.
> >
>
> I agree. The basic features of the API should work with just an MPU,
> say with 4 regions? That seems like a good "minimum requirement" to
> design toward. HW with more regions or MMU (remapping, TLB) may
> provide other optional features.
>
> This means that the 1:1 VA-PA mapping should continue to be
> implied/understood in the design, and can be assumed in general.
>
> > Peter
> > -----------------
> > Peter Dufault
> > HD Associates, Inc.      Software and System Engineering
> >
> > This email is delivered through the public internet using protocols
> subject to interception and tampering.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200315/412b00be/attachment-0001.html>