ARM 上的内核入口点

Question

我正在阅读 ARM 内核源代码以更好地理解并发现一些有趣的东西。

在arch/arm/kernel/entry-armv.S 内部有一个名为vector_stub 的宏，它生成一小块程序集，然后是各种ARM 模式的跳转表。例如，对vector_stub irq, IRQ_MODE, 4 的调用导致宏扩展为带有标签vector_irq 的主体； vector_dabt、vector_pabt、vector_und 和 vector_fiq 也是如此。

在这些 vector_* 跳转表中的每一个中，恰好有 1 个DWORD，其地址为带有_usr 后缀的标签。

我想确认我的理解是准确的，请见下文。

1. 这是否意味着带有_usr 后缀的标签仅在该CPU 上执行的内核线程处于用户空间上下文时出现中断时才被执行？例如，irq_usr 在内核线程处于用户空间上下文时发生中断时执行，dabt_usr 在内核线程处于用户空间上下文时发生中断时执行，依此类推。
2. 如果 [1] 为真，那么哪些内核线程负责处理，比如 irqs，具有不同的后缀，例如 irq_svc。我假设这是在 SVC 模式下发生的中断请求的处理程序。如果是这样，哪个内核线程处理这个？当前处于 SVC 模式的内核线程，在哪个 CPU 上接收中断？
3. 如果 [2] 为真，那么内核线程在什么时候完成对第二个中断的处理，并返回到它停止的位置（也在 SVC 模式下）？是ret_from_intr吗？

Answer 1

在每个 vector_* 跳转表中，恰好有 1 个DWORD，其地址为带有_usr 后缀的标签。

这是正确的。按当前模式索引的表。例如，irq 只有三个条目； irq_usr、irq_svc 和 irq_invalid。在数据中止、FIQ 和其他模式期间应禁用 Irq。在这段简短的“向量存根”代码之后，Linux 将总是转换到 svc 模式。它是通过，

@
@ Prepare for SVC32 mode.  IRQs remain disabled.
@
mrs r0, cpsr
eor r0, r0, #(\mode ^ SVC_MODE | PSR_ISETSTATE)
msr spsr_cxsf, r0

@@@ ... other unrelated code

movs    pc, lr          @ branch to handler in SVC mode

这就是为什么irq_invalid 用于所有其他模式。执行此向量存根代码时绝不应发生异常。

这是否意味着只有在该 CPU 上执行的内核线程处于用户空间上下文中时出现中断时才会执行带有 _usr 后缀的标签？例如，如果内核线程处于用户空间上下文时发生中断，则执行 irq_usr，如果内核线程处于用户空间上下文时发生中断，则执行 dabt_usr，依此类推。

是的，spsr 是中断模式，表按这些模式位索引。

如果1 为真，那么哪些内核线程负责处理，比如irqs，具有不同的后缀，例如irq_svc。我假设这是在 SVC 模式下发生的中断请求的处理程序。如果是这样，哪个内核线程处理这个？当前处于 SVC 模式的内核线程，在哪个 CPU 上接收中断？

我认为你在这里有一些误解。用户空间进程有一个“内核线程”。 irq_usr 负责存储用户模式寄存器，因为可能会发生重新调度。 irq_svc 的上下文不同，因为内核堆栈正在使用中，它与 IRQ 代码将使用的相同。当用户任务调用read() 时会发生什么？它使用系统调用和代码在内核上下文中执行。每个进程都有一个用户和 svc/内核堆栈（和线程信息）。内核线程是一个没有任何用户空间堆栈的进程。

如果2 为真，那么内核线程在什么时候完成对第二个中断的处理，并返回到它停止的地方（同样在 SVC 模式下）？是ret_from_intr吗？

通常 Linux 会返回被中断的内核线程，以便它可以完成它的工作。但是，有一个用于抢占 svc 线程/上下文的配置选项。如果中断导致重新调度事件，则如果CONFIG_PREEMPT 处于活动状态，则可能会导致进程/上下文切换。有关此代码，请参阅 svc_preempt。

另见：

• Linux kernel arm exception stack init
• Arm specific irq initialization