Context switching through an ISR in RTEMS

[Gedare Bloom]

On Mon, Aug 17, 2020 at 10:30 AM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>
>
>
> On Mon, Aug 17, 2020 at 9:24 PM Gedare Bloom <gedare at rtems.org> wrote:
>>
>> On Mon, Aug 17, 2020 at 5:53 AM Utkarsh Rai <utkarsh.rai60 at gmail.com> wrote:
>> >
>> >
>> >
>> > 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.
>>
>> Great. Now, a question: can the Idle Task and Interrupt Stack share
>> the same 4K page?
>
>
> 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)?

All this page-alignment stuff might be wasting a lot of space for
stacks that are smaller than 4K size. So, could you allocate them both
in the same 4K region?