<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 9:24 PM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</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 Mon, Aug 17, 2020 at 5:53 AM Utkarsh Rai <<a href="mailto:utkarsh.rai60@gmail.com" target="_blank">utkarsh.rai60@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Aug 17, 2020 at 11:32 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>> wrote:<br>
>><br>
>> 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>
><br>
><br>
> Thank you, this solves the issue.<br>
><br>
> I have used,<br>
> #define CPU_INTERRUPT_STACK_ALIGNMENT 4096, in the application code as well as cpu.h, to align for 4K pages.<br>
<br>
Great. Now, a question: can the Idle Task and Interrupt Stack share<br>
the same 4K page?<br></blockquote><div><br></div><div>I am not sure whether you mean if they should have the same address or if they have overlapping addresses ( For example if the idle thread stack is at 0x202e40 and interrupt stack is at 0x204e40 then they should have the 0x20300-0x20400 address as common)? </div></div></div>