Nested Interrupt Handling in ARM

4
votes

Below is the flow mentioned in the Cortex A Prog Guide, I have a few questions on the text.

A reentrant interrupt handler must therefore take the following steps after an IRQ exception is raised and control is transferred to the interrupt handler in the way previously described.

• The interrupt handler saves the context of the interrupted program (that is, it pushes onto the alternative kernel mode stack any registers which will be corrupted by the handler, including the return address and SPSR_IRQ).

Q> What is the alternative kernel mode stack here ?

• It determines which interrupt source needs to be processed and clears the source in the external hardware (preventing it from immediately triggering another interrupt).

• The interrupt handler changes the processor to the other kernel mode, leaving the CPSR I bit set (interrupts are still disabled).

Q> From IRQ to SVC mode with CPSR.I =1 . Right ?

• The interrupt handler saves the exception return address on the stack (a stack for the new mode, located in kernel memory) and re-enables interrupts.

Q> Are there 2 stacks here ?

• It calls the appropriate C handler for the original interrupt (interrupts are still disabled).

• Upon completion, the interrupt handler disables IRQ and pops the exception return address from the stack.

• It restores the context of the interrupted program directly from the alternative kernel mode stack. This includes restoring the PC, and the CPSR which switches back to the previous execution mode.

Q> How is the nesting done here ? I am bit confused here...
1
linux-kernelarm
Your questions are always confusing. Are you talking about the way Linux does it or they way you want to change Linux to do it? If I answer, your questions, you just ask 20 more. See: Level triggered and nested interrupts. A typical kernel has one stack for normal work. It is often switched (esp. w Linux) for each task. You asked another question about irq_svc, etc in entry-armv.S. – artless noise
This has an alternate stack at the top of the question. The arrays must be bigger if we want nesting; depending on how you do it. There is no one way to do interrupts on the ARM; they give us flexibility as system programmers. – artless noise
The lack of documentation and confusing documentation/manuals in books create issues, so If i ask one question and then try to relate it, it does not fit in. The problem here is that Cortex A explains one way while linux chose to do another way. I am implementing a bare metal RTOS and so when i take reference from linux the problem comes. – user435739

1 Answers

1
votes

1) Up to you, really. The requirement is that it is one that cannot be asynchronously invoked. So you can use System mode stack, which is shared with User mode - with some interesting implications. Or you can use the Supervisor mode stack, as long as you always properly store all context before executing an SVC instruction.

2) Yes.

3) Yes, you store the context on a stack for whichever mode picked in (1).

4) While executing in the alternative mode, you re-enable interrupts (as your text states). At this point, the processor will now react to new interrupts signalled to the core - generally ones of a higher priority as configured in your interrupt controller.