Linux 中断 —— GIC (中断生命周期)

经过前面的分析可以看出一个中断从产生、执行，到最终结束的流程。这里我们用树形代码路径来简要分析一下一个中断的生命周期：

vector_irq()->vector_irq()->__irq_svc()

  ->svc_entry()--------------------------------------------------------------------------保护中断现场

  ->irq_handler()->gic_handle_irq()------------------------------------------------具体到GIC中断控制器对应的就是gic_handle_irq()，此处从架构相关进入了GIC相关处理。

    ->GIC_CPU_INTACK--------------------------------------------------------------读取IAR寄存器，响应中断。

    ->handle_domain_irq()

      ->irq_enter()------------------------------------------------------------------------进入硬中断上下文

      ->generic_handle_irq()

        ->generic_handle_irq_desc()->handle_fasteoi_irq()--------------------根据中断号分辨不同类型的中断，对应不同处理函数，这里中断号取大于等于32。

          ->handle_irq_event()->handle_irq_event_percpu()

            ->action->handler()-----------------------------------------------------------对应到特定中断的处理函数，即上半部。

              ->__irq_wake_thread()-----------------------------------------------------如果中断函数处理返回IRQ_WAKE_THREAD，则唤醒中断线程进行处理，但不是立即执行中断线程。

      ->irq_exit()---------------------------------------------------------------------------退出硬中断上下文。视情况处理软中断。

        ->invoke_softirq()-----------------------------------------------------------------处理软中断，超出一定条件任务就会交给软中断线程处理。

    ->GIC_CPU_EOI--------------------------------------------------------------------写EOI寄存器，表示结束中断。至此GIC才会接收新的硬件中断，此前一直是屏蔽硬件中断的。

  ->svc_exit-------------------------------------------------------------------------------恢复中断现场

 

• 中断上半部的处理是关硬件中断的，这里的关硬件中断是GIC就不接收中断处理。直到写EOI之后，GIC仲裁单元才会重新选择中断进行处理。
• 软中断运行于软中断上下文中，但是仍然是关硬件中断的，这里需要特别注意，软中断需要快速处理并且不能睡眠。
• 不是所有软中断都运行于软中断上下文中，部分软中断任务可能会交给ksoftirqd线程处理。
• 包括IRQ_WAKE_THREAD、ksoftirqd、woker等唤醒线程的情况，都不会在中断上下文中进行处理。中断上下文中所做的处理只是唤醒，执行时机交给系统调度。
• 如果要提高Linux实时性，有两个要点：一是将上半部线程化；另一个是将软中断都交给ksoftirqd线程处理。