Context switching through an ISR in RTEMS

[Utkarsh Rai]

On Mon, Aug 17, 2020 at 11:32 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

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

Thank you, this solves the issue.

I have used,
 #define CPU_INTERRUPT_STACK_ALIGNMENT 4096,  in the application code as
well as cpu.h, to align for 4K pages.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200817/48b11e46/attachment.html>