<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 17, 2020 at 11:32 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">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">On 16/08/2020 18:09, Utkarsh Rai wrote:<br>
<br>
><br>
><br>
> On Sun, Aug 16, 2020 at 9:18 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a> <br>
> <mailto:<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>>> wrote:<br>
><br>
> On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai<br>
> <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a> <mailto:<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>>> wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai<br>
> <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a> <mailto:<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>>> wrote:<br>
> >><br>
> >><br>
> >><br>
> >> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a><br>
> <mailto:<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>>> wrote:<br>
> >>><br>
> >>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai<br>
> <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a> <mailto:<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>>> wrote:<br>
> >>> ><br>
> >>> ><br>
> >>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai<br>
> <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a> <mailto:<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>>> wrote:<br>
> >>> >><br>
> >>> >> Thanks, I'll check them out.<br>
> >>> >><br>
> >>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom<br>
> <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a> <mailto:<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>>> wrote:<br>
> >>> >>><br>
> >>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai<br>
> <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a> <mailto:<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>>> wrote:<br>
> >>> >>> ><br>
> >>> >>> > Hello,<br>
> >>> >>> > I have been testing my code for thread stack isolation<br>
> against various tests( Some written by me, and remaining already<br>
> present). One of the limitations that I have found is that I<br>
> encounter fatal errors whenever a context switch takes place<br>
> through an ISR. Can you please explain how the context switching<br>
> procedure works when an interrupt occurs. When I use gdb for<br>
> stepping through the code it asynchronously moves to context<br>
> switching code from the executing thread( for example psx16 test).<br>
> >>> >>> > For thread stack protection, the part that deals with<br>
> context switching simply 'sets 'the memory entries of the heir<br>
> stack and 'unsets' that of the executing stack.<br>
> >>> >>><br>
> >>> >>> There are two issues to start: interrupt stacks and<br>
> dispatching from an ISR.<br>
> >>> >>><br>
> >>> >>> I think you can start by reading some of the documentation:<br>
> >>> >>><br>
> <a href="https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/c-user/interrupt_manager.html#processing-an-interrupt</a><br>
> >>> >>><br>
> >>> >>><br>
> <a href="https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/c-user/scheduling_concepts.html#dispatching-tasks</a><br>
> >>> >>><br>
> >>> >>><br>
> <a href="https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/c-user/config/general.html#configure-interrupt-stack-size</a><br>
> >>> >>><br>
> >>> >>><br>
> <a href="https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing" rel="noreferrer" target="_blank">https://docs.rtems.org/branches/master/cpu-supplement/port.html#interrupt-processing</a><br>
> >>> >>><br>
> >>> >>> You can also find some material in rtems-docs.git/porting<br>
> -- I don't<br>
> >>> >>> know where that gets generated.<br>
> >>> >>><br>
> >>> >>> Continue to ask questions, and writing blog posts.<br>
> >>> ><br>
> >>> ><br>
> >>> > So after going through the materials, I was able to<br>
> understand how an ISR is registered, ISR stack initialization.<br>
> What is still not clear to me is what are the differences between<br>
> dispatching a task in ISR different and a normal context-switch?<br>
> >>> ><br>
> >>> > For example the psxsignal06 test, we wait for a signal<br>
> here, on setting the breakpoint at the context switch code<br>
> (cpu_asm.S), after this line, I find that the heir context stack<br>
> is the ISR stack. The next thread is dispatched from this ISR but<br>
> as soon as I unset the memory attributes of the ISR stack I get a<br>
> fatal error. One possible reason is that the ISR stack is not page<br>
> aligned and unsettling its attributes unsets nearby memory<br>
> regions. Is there something else that I am missing?<br>
> >>> ><br>
> >>> what else is on the same page as the ISR stack?<br>
> >>><br>
> >><br>
> >> The idle thread stack is between 0x202e40 to 0x203e40 and the<br>
> ISR stack is between 0x203e40 to 0x204e40. So when we unset the<br>
> memory for the ISR it unsets between 0x203000 to 0x205000, I think<br>
> this may be the problem.<br>
> >><br>
> >><br>
> >>><br>
> >>> Not quite related, you'll need to also make sure to map the<br>
> ISR stack<br>
> >>> back in during ISR Handling, before using it.<br>
> >><br>
> >><br>
> >> When the ISR gets called for the first time, it already has R/W<br>
> permission and for subsequent context switches it's memory entry<br>
> is accordingly set/unset.<br>
> ><br>
> ><br>
> > The idle thread stack and the ISR stack are placed at these<br>
> addresses with the BSP specific linker script as "rtemsstack.idle"<br>
> and "rtemsstack.interrupt". So to make them page-aligned we may<br>
> have to make changes in the lnker script.<br>
><br>
> Give it a try. It should be relatively easy to hack in a couple of<br>
> alignments.<br>
><br>
> We can discuss later the correctness of that.<br>
><br>
> Ok, I will report how it goes.<br>
<br>
Please use the CPU port option<br>
<br>
#define CPU_INTERRUPT_STACK_ALIGNMENT CPU_CACHE_LINE_BYTES<br>
<br>
to define the interrupt and idle stack alignment. There is no need to <br>
change the linker command file.<br></blockquote><div><br></div><div>Thank you, this solves the issue.</div><div><br></div><div>I have used,</div><div> #define CPU_INTERRUPT_STACK_ALIGNMENT 4096, in the application code as well as cpu.h, to align for 4K pages.</div></div></div>