> On Mar 14, 2020, at 14:22 , Gedare Bloom <ged...@rtems.org> wrote:
>
> Hi Utkarsh,
>
> On Sat, Mar 14, 2020 at 12:05 PM Utkarsh Rai <utkarsh.ra...@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.ra...@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.
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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
