为了更好地理解我，我正在阅读ARM内核源代码，并发现了一些有趣的东西。
内部arch/arm/kernel/entry-armv.S有一个名为的宏vector_stub，该宏生成一小部分程序集，然后生成用于各种ARM模式的跳转表。例如，有一个调用vector_stub irq, IRQ_MODE, 4使该宏扩展为带有label的主体vector_irq；和相同的发生vector_dabt，vector_pabt，vector_und，和vector_fiq。
在每个vector_ *跳转表中，DWORD带_usr后缀的标签地址正好为1 。
我想确认我的理解是正确的，请参阅下文。
_usr只有当在该CPU上执行的内核线程在用户空间上下文中发生中断时，才执行带有后缀的标签？例如，irq_usr如果在内核线程处于用户空间上下文中时发生中断，则执行；如果在内核线程处于用户空间上下文中dabt_usr时发生中断，则执行，等等。irq_svc。我假设这是在SVC模式下发生的中断请求的处理程序。如果是这样，哪个内核线程可以处理此问题？当前处于SVC模式的内核线程，在哪个CPU上接收到中断？ret_from_intr吗在每个vector_ *跳转表中，
DWORD带_usr后缀的标签地址正好为1 。
这是对的。该表已被当前模式索引。例如，irq只有三个条目。irq_usr，irq_svc和irq_invalid。在数据中止，FIQ和其他模式期间，应禁用Irq。在简短的“ vector stub”代码之后，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为true，那么负责处理内核的线程（例如irqs）具有不同的后缀，例如irq_svc。我假设这是在SVC模式下发生的中断请求的处理程序。如果是这样，哪个内核线程可以处理此问题？当前处于SVC模式的内核线程，在哪个CPU上接收到中断？
我觉得您在这里有些误会。用户空间进程有一个“内核线程”。该irq_usr负责存储用户模式寄存器，重新安排可能发生。由于irq_svc使用了内核堆栈，因此上下文有所不同，并且IRQ代码将使用相同的上下文。用户任务调用时会发生什么read()？它使用系统调用，并且代码在内核上下文中执行。每个进程都具有用户和svc /内核堆栈（以及线程信息）。内核线程是没有任何用户空间堆栈的进程。
如果2为true，那么内核线程在什么时候完成第二个中断的处理，并返回到中断处（在SVC模式下）？是
ret_from_intr吗
通常，Linux返回被中断的内核线程，以便它可以完成工作。但是，有一个配置选项可用于抢占svc线程/上下文。如果该中断导致重新安排事件，则如果处于活动状态，则可能导致进程/上下文切换CONFIG_PREEMPT。请参阅svc_preempt此代码。
也可以看看：
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句