On Sat, Mar 14, 2020 at 4:07 PM <dufa...@hda.com> wrote: > > > > > 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. >
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. > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
