Context switching through an ISR in RTEMS

[Utkarsh Rai]

On Sun, Aug 16, 2020 at 9:18 PM Gedare Bloom <gedare at rtems.org> wrote:

> On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai <utkarsh.rai60 at gmail.com>
> wrote:
> >
> >
> >
> > On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai <utkarsh.rai60 at gmail.com>
> wrote:
> >>
> >>
> >>
> >> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom <gedare at rtems.org> wrote:
> >>>
> >>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai <utkarsh.rai60 at gmail.com>
> wrote:
> >>> >
> >>> >
> >>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai <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>
> wrote:
> >>> >>>
> >>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai <
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200816/25a0f87b/attachment.html>