<div dir="auto"><div>Utkarsh,<div dir="auto"><br></div><div dir="auto">What do you mean by "This would although mean that we would have page tables of  1MB."</div><div dir="auto"><br></div>Check that you use plain text when inlining a reply, or at least that you broke the reply format.</div><div dir="auto"><br></div><div dir="auto">Gedare<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, May 15, 2020, 6:04 PM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com">utkarsh.rai60@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 14, 2020 at 10:23 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Utkarsh Rai,<br>
<br>
On 13/05/2020 14:30, Utkarsh Rai wrote:<br>
> Hello,<br>
> My GSoC project,  providing thread stack protection support, has to be <br>
> a user-configurable feature.<br>
> My question is,  what would be the best way to implement this, my idea <br>
> was to model it based on the existing system configuration <br>
> <<a href="https://docs.rtems.org/branches/master/c-user/config/intro.html" rel="noreferrer noreferrer" target="_blank">https://docs.rtems.org/branches/master/c-user/config/intro.html</a>>, but <br>
> Dr. Gedare pointed out that configuration is undergoing heavy changes <br>
> and may look completely different in future releases. Kindly advise me <br>
> as to what would be the best way to proceed.<br>
before we start with an implementation. It would be good to define what <br>
a thread stack protection support is supposed to do.</blockquote><div><br></div><div>The thread stack protection mechanism will protect against stack overflow errors and will completely isolate the thread stacks from each other. Sharing of thread stack will be possible only when the user makes explicit calls to do so. More details about this can be found in<a href="https://lists.rtems.org/pipermail/devel/2020-May/059768.html" target="_blank" rel="noreferrer"> this thread</a>.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Then there should <br>
be a concept for systems with a Memory Protection Unit (MPU) and a <br>
concept for systems with a Memory Management Unit (MMU). MMUs may <br>
provide normal 4KiB Pages, large Pages (for example 1MiB) or something <br>
more flexible. We should identify BSPs which should have support for <br>
this. For each BSP should be a concept. Then we should think about how a <br>
user can configure this feature. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">For memory protection will have a 1:1 VA-PA address translation that means a 4KiB page size will be set for both the MPU and MMU, a 1:1 mapping will ensure we will have to do lesser page table walks.This would although mean that we would have page tables of  1MB. I will be first providing the support for Armv7 based BSPs (RPi , BBB, etc. have MMU support) then when I have a working example I will move on to provide the support for RISC-V. which has MPU support.   </blockquote></div></div>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank" rel="noreferrer">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote></div></div></div>