ARM 中的嵌套中断处理答案

【问题标题】：Nested Interrupt Handling in ARMARM 中的嵌套中断处理
【发布时间】：2014-06-12 23:53:56
【问题描述】：

以下是 Cortex A Prog Guide 中提到的流程，文中我有几个问题。

因此，在引发 IRQ 异常并按照前面描述的方式将控制权转移到中断处理程序后，可重入中断处理程序必须采取以下步骤。

• 中断处理程序保存被中断程序的上下文（也就是说，它将任何将被处理程序破坏的寄存器，包括返回地址和 SPSR_IRQ 都压入备用内核模式堆栈）。

Q> What is the alternative kernel mode stack here ?

• 确定需要处理哪个中断源，并在外部硬件中清除该源（防止它立即触发另一个中断）。

• 中断处理程序将处理器更改为其他内核模式，保持 CPSR I 位设置（中断仍被禁用）。

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

• 中断处理程序将异常返回地址保存在堆栈（新模式的堆栈，位于内核内存中）并重新启用中断。

Q> Are there 2 stacks here ?

• 它为原始中断调用适当的 C 处理程序（中断仍然被禁用）。

• 完成后，中断处理程序禁用 IRQ 并从堆栈中弹出异常返回地址。

• 它直接从备用内核模式堆栈恢复被中断程序的上下文。这包括恢复 PC，以及切换回之前执行模式的 CPSR。

Q> How is the nesting done here ? I am bit confused here...

【问题讨论】：

您的问题总是令人困惑。您是在谈论 Linux 的执行方式还是您想要更改 Linux 来执行此操作的方式？如果我回答你的问题，你只需要再问 20 个。请参阅：Level triggered and nested interrupts。一个典型的内核有一个用于正常工作的堆栈。它经常为每个任务切换（尤其是使用 Linux）。你在 entry-armv.S 中问了关于irq_svc 等的另一个问题。
问题顶部有一个alternate stack。如果我们想要嵌套，数组必须更大；取决于你怎么做。在 ARM 上进行中断没有一种方法；它们为我们作为系统程序员提供了灵活性。
书籍中缺乏文档和混乱的文档/手册会造成问题，所以如果我问一个问题然后尝试关联它，它不适合。这里的问题是 Cortex A 解释了一个方式而linux选择了另一种方式。我正在实现一个裸机 RTOS，所以当我参考 linux 时，问题就来了。

【解决方案1】：

1) 由你决定，真的。要求是它不能被异步调用。因此，您可以使用与用户模式共享的系统模式堆栈 - 具有一些有趣的含义。或者您可以使用主管模式堆栈，只要您始终在执行 SVC 指令之前正确存储所有上下文。

2) 是的。

3) 是的，对于 (1) 中选择的任何模式，您都将上下文存储在堆栈中。

4) 在替代模式下执行时，您重新启用中断（如您的文本所述）。此时，处理器现在将对向内核发出信号的新中断做出反应——通常是中断控制器中配置的更高优先级的中断。

【讨论】：