Linux中断管理
CPU和外设之间的交互，或CPU通过轮询机制查询，或外设通过中断机制主动上报。
对大部分外设中断比轮询效率高，但比如网卡驱动采取轮询比中断效率高。
这里重点关注ARM+Linux组合下中断管理，从底层硬件GIC+CPU，到Linux内核通用部分处理，再到GIC驱动以及中断注册，最后是中断下半部软终端、tasklet、workqueue，包括线程化部分。
所以按照从硬件到软件，软件从底层到上层的框架去介绍。
0. 目录
1. 思考问答
- 发生硬件中断后，ARM处理器做了哪些事情？
SoC内部中断控制器会感知到中断信号，中断控制器里的仲裁单元(Distributor)会在众多CUP核心中选择一个，并把该中断分发给CPU核心。
GIC控制器和CPU核心之间通过一个nIRQ信号来通知CPU。
CPU核心感知到中断发生之后，硬件会自动做如下一些事情：
- 保存中断发生时CPSR寄存器的内容到SPSR_irq寄存器中
- 修改CPSR寄存器，让CPU进入处理器模式中的IRQ模式，即CPSR寄存器中的M域设置为IRQ Mode
- 硬件自动关闭中断IRQ或FIQ，即CPSR中的IRQ位或FIQ位置1
- 保存返回地址到LR_irq寄存器中
- 硬件自动跳转到中断向量表的IRQ向量中
- 硬件中断号和Linux内核的IRQ中断号是如何映射的？
硬件中断号的映射是在系统启动过程中接卸DTS，然后经由irq_domain_alloc_irqs()完成映射到Linux中断号。
中断发生后，根据硬件中断号经由irq_find_mapping()找到Linux软中断号。
- 一个硬件中断发生后，Linux内核如何响应并处理该中断？
一个硬件发生后，LInux软件的起点是中断向量表vector_irq。
vector_irq根据中断发生时状态决定是进入用户空间__irq_svc还是内核空间__irq_svc。
两者主要工作都交给irq_handler处理，irq_handler调用中断控制器处理函数gic_handle_irq()。
gic_handle_irq()根据读取到的硬件中断号转换成Linux中断号，然后进行特定中断处理。
从中断返回时，还需要实现如下两个操作：
- 从SPSR_irq寄存器中恢复数据到CPSR中
- 从LR_irq中回复内容到PC中，从而返回到中断点的下一个指令处执行。
- 为什么说中断上下文不能执行睡眠操作？
所谓的睡眠，就是调用schedule()让出CPU，调度器选择另外一个进程继续执行，这个过程涉及进程栈空间的切换。
如果中断上下文中调用schedule()，此时获取的struct thread_info数据结构是发生中断是该进程栈信息，而不是中断上下文调用schedule()时任何信息。
这就导致再也无法返回中断上下文中调用schedule()的地方。
另一个原因是，中断上下文处于关中断中，需要发送一个EOI通知GIC中断处理结束，GIC和CPU Interface才会进入下一次中断处理。如果中途schedule()，那么整个系统的中断都会被屏蔽掉。
- 软中断的回调函数执行过程中是否允许响应本地中断？
软中断回调函数执行处于开中断环境下，所以允许响应本地中断。
具体参考__do_softirq()，在执行h->action()前打开本地中断，完成后关闭中断。
- 同一类型的软中断是否允许多个CPU并行执行？
同一类型的软中断可以在多个CUP并发执行，因为软中断处理函数是可重入的，自身对数据进行了保护。
- 软中断上下文包括哪几种情况？
中断上下文包括硬中断上下文和软中断上下文，当然也包括NMI上下文。
软中断上下文包括三部分：
一是在下半部执行的软中断处理包括tasklet，调用过程是irq_exit()->invoke_softirq()；
二是ksoftirqd内核线程执行的软中断，比如强制中断线程化force_threads，或者软中断执行时间太长仅为唤醒ksoftirqd内核线程；
三是进程上下文中调用local_bh_enable()时也会去执行软中断处理，调用过程是local_bh_enable()->do_softirq()。
一属于传统意义的中断上下文，二、三运行在进程上下文中，但三者统称为软中断上下文。
- 软中断上下文和进程上下文哪个优先级高？为什么？
软中断上下文优先级高于进程上下文，因此软中断包括tasklet总是抢占进程的运行。参见irq_exit()退出中断时优先执行softirq。
比如当进程A在运行时发生中断，在中断返回时如果不处于中断上下文且有pending的softirq时，优先执行软中断包括tasklet。
然后采取检查是否有高优先级任务需要签章中断点的进程。
这样导致的危害是：如果执行软中断或者tasklet事件过长，那么高优先级任务就长时间得不到运行，严重影响系统的实时性。
这也是RT补丁强制将softirq处理函数线程化的原因。
- 是否允许同一个tasklet在多个CPU上并行执行？
不允许同一个tasklet同时在多个CPU并发执行，taskelt必须固定在一个CPU上串行执行。
因为tasket被挂入到per-cpu的taskelt_vec中，并且设置TASKLET_STATE_SCHED标志位，那么只能由该CPU来执行。
直到执行完毕并清除了TASKLET_STATE_SCHED后，其它CPU才有机会执行。
- workqueue试运行在中断上下文，还是进程上下文？其回调函数允许睡眠吗？
- 旧版本(Linux 2.6.25)的workqueue机制在实际过程中遇到了哪些问题和挑战？
- CMWQ机制如何动态管理工作线程池的线程呢？
- 如果有多个work挂入一个工作线程中执行，当某个work的回调函数执行了阻塞操作，那么剩下的work该怎么办？
