On Mon, Aug 17, 2020 at 11:56 AM Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: > > > > On Mon, Aug 17, 2020 at 10:12 PM Gedare Bloom <ged...@rtems.org> wrote: >> >> On Mon, Aug 17, 2020 at 10:30 AM Utkarsh Rai <utkarsh.ra...@gmail.com> wrote: >> > >> > >> > >> > On Mon, Aug 17, 2020 at 9:24 PM Gedare Bloom <ged...@rtems.org> wrote: >> >> >> >> On Mon, Aug 17, 2020 at 5:53 AM Utkarsh Rai <utkarsh.ra...@gmail.com> >> >> wrote: >> >> > >> >> > >> >> > >> >> > On Mon, Aug 17, 2020 at 11:32 AM Sebastian Huber >> >> > <sebastian.hu...@embedded-brains.de> wrote: >> >> >> >> >> >> On 16/08/2020 18:09, Utkarsh Rai wrote: >> >> >> >> >> >> > >> >> >> > >> >> >> > On Sun, Aug 16, 2020 at 9:18 PM Gedare Bloom <ged...@rtems.org >> >> >> > <mailto:ged...@rtems.org>> wrote: >> >> >> > >> >> >> > On Sat, Aug 15, 2020 at 9:03 PM Utkarsh Rai >> >> >> > <utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote: >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > On Sun, Aug 16, 2020 at 6:12 AM Utkarsh Rai >> >> >> > <utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote: >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> On Sat, Aug 15, 2020 at 7:26 PM Gedare Bloom <ged...@rtems.org >> >> >> > <mailto:ged...@rtems.org>> wrote: >> >> >> > >>> >> >> >> > >>> On Sat, Aug 15, 2020 at 6:26 AM Utkarsh Rai >> >> >> > <utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote: >> >> >> > >>> > >> >> >> > >>> > >> >> >> > >>> > On Thu, Aug 13, 2020 at 5:10 AM Utkarsh Rai >> >> >> > <utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@gmail.com>> wrote: >> >> >> > >>> >> >> >> >> > >>> >> Thanks, I'll check them out. >> >> >> > >>> >> >> >> >> > >>> >> On Thu, Aug 13, 2020 at 12:56 AM Gedare Bloom >> >> >> > <ged...@rtems.org <mailto:ged...@rtems.org>> wrote: >> >> >> > >>> >>> >> >> >> > >>> >>> On Wed, Aug 12, 2020 at 11:33 AM Utkarsh Rai >> >> >> > <utkarsh.ra...@gmail.com <mailto:utkarsh.ra...@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? > > > The stacks are placed at different addresses using the linker script by " > *(SORT_BY_ALIGNMENT (SORT_BY_NAME (.rtemsstack*))) " and each of them have 4k > sizes by default. This means that we have to have the same addresses for both > the ISR and the idle stacks if we want them in the same 4K region. > Also, we have a minimum stack size as 4K by default, so at max, we would be > wasting a single page.
Oh, ok. I was not aware they were already 4K stacks. That's probably overkill but not so important to optimize it. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
