第4章 Intel平台中断处理机制：APIC与IOAPIC架构
中断处理，说白了就是CPU怎么响应外部事件。我做了这么多年实时系统，最深的体会就是：不懂中断，就别谈实时。Intel平台的中断机制，从古老的8259A到现在的APIC/IOAPIC，进化了不止一个量级。今天咱们就把它掰开揉碎了讲清楚。
4.1 APIC与IOAPIC：现代Intel中断的基石
先说说APIC（Advanced Programmable Interrupt Controller）。这玩意儿分两部分：Local APIC 和 I/O APIC。Local APIC在CPU内部，每个核都有一个。I/O APIC在芯片组里，负责收集外设的中断信号。
我刚开始接触多核系统时，有个困惑：为什么中断不能直接发给CPU？后来才明白，没有APIC，多核系统根本没法玩。你想啊，一个网卡发中断，如果直接拉CPU的INTR引脚，那到底该哪个核处理？
核心架构图（逻辑示意）
外设 → I/O APIC → 系统总线 → Local APIC(核0)
→ Local APIC(核1)
→ Local APIC(核2)
→ Local APIC(核3)I/O APIC负责把中断路由到指定的CPU核。每个I/O APIC有24个中断引脚（有些芯片组更多），每个引脚都可以独立编程。你可以指定：这个中断发给哪个核、用哪个向量号、触发方式是边沿还是电平。
个人经验：我在做工业控制器时，遇到过I/O APIC的引脚分配问题。有个PCIe设备死活不触发中断，查了半天发现是I/O APIC的引脚被BIOS默认分配给了别的设备。后来在ACPI表里手动重映射才解决。嗯，ACPI表里的中断映射一定要仔细核对。
4.2 中断优先级管理：谁先谁后？
实时系统里，中断优先级就是命根子。Intel的APIC支持256个中断向量，优先级从0到255。数值越大，优先级越高。但实际可用的没那么多，有些被CPU内部用了。
优先级管理有几个关键点：
- 向量号0-31：保留给CPU异常和NMI，你动不了
- 向量号32-255：用户可用的中断，其中32-47通常留给ISA设备
- 优先级分组：每16个向量一组，比如32-47是一组，48-63是另一组
为什么会这样分组？说白了是为了兼容老旧的8259A。但现代系统里，我建议你尽量使用高优先级向量（比如200以上）给实时任务。我在一个运动控制项目中，把伺服驱动的中断设成了向量220，优先级远高于网卡和USB，效果立竿见影。
注意：别把所有中断都设成最高优先级。我曾经见过一个系统，把所有中断都映射到向量255，结果高优先级中断互相抢占，CPU上下文切换开销暴涨30%。优先级要按需分配，不是越高越好。
4.3 中断嵌套与屏蔽：实时系统的双刃剑
中断嵌套，就是高优先级中断打断低优先级中断的处理。Intel的APIC默认支持嵌套，但有个关键寄存器叫TPR（Task Priority Register）。CPU当前正在处理的中断优先级，会写入TPR。只有优先级高于TPR的中断才能被响应。
我个人的习惯是：在实时任务的关键路径上，临时抬高TPR。比如这样：
// 临时屏蔽所有低于200的中断
void enter_critical_section(void) {
uint32_t tpr = read_apic_reg(APIC_TPR);
write_apic_reg(APIC_TPR, 0xC8); // 0xC8 = 200
// 保存旧值，后面恢复
saved_tpr = tpr;
}
void exit_critical_section(void) {
write_apic_reg(APIC_TPR, saved_tpr);
}但这里有个坑：TPR只能屏蔽低于它的中断，不能屏蔽NMI和SMI。我在一个基站项目中，NMI频繁触发，导致实时任务抖动。后来发现是内存ECC错误触发了NMI，最后通过硬件修复才解决。嗯，NMI和SMI是绕不过去的坎，设计时一定要考虑它们的开销。
4.4 中断延迟优化技巧：从硬件到软件
中断延迟，就是从外设发出中断信号，到CPU开始执行ISR（中断服务程序）的时间。这个时间越短，实时性越好。我总结了几条实战经验：
| 优化方向 | 具体方法 | 效果 |
|---|---|---|
| 硬件层面 | 使用MSI-X代替传统引脚中断 | 减少I/O APIC转发延迟 |
| 中断分配 | 将实时中断绑定到专用核 | 避免核间中断迁移 |
| 向量选择 | 使用高优先级向量（200+） | 减少被其他中断抢占的概率 |
| ISR优化 | ISR只做最必要的工作，其余交给tasklet | 缩短关中断时间 |
| 缓存预热 | 在ISR入口预取关键数据 | 减少cache miss延迟 |
我记得有一次做音频处理系统，中断延迟要求低于10微秒。硬件上用了MSI-X，软件上把ISR精简到只有20条指令。但测试时发现偶尔会跳到30微秒。查了三天，最后发现是ACPI的C-State导致CPU进入了深度睡眠，唤醒延迟巨大。解决办法：在BIOS里禁用C-State，或者用内核参数 intel_idle.max_cstate=0。
避坑指南：我曾经在调试一个实时系统时，发现中断延迟忽高忽低。用示波器量了外设的中断引脚，信号很干净。后来用perf工具看中断分布，发现有个核的中断负载特别高。原来是因为irqbalance服务把中断都集中到了一个核上。手动设置中断亲和性后，问题解决。
4.5 实战：测量中断延迟
光说不练假把式。我一般用这种方法测量中断延迟：
// 测量中断延迟的简单方法
static uint64_t tsc_start, tsc_end;
void my_isr(void) {
tsc_end = rdtsc();
uint64_t latency = tsc_end - tsc_start;
// 记录延迟到环形缓冲区
record_latency(latency);
// 实际中断处理...
}
void trigger_interrupt(void) {
tsc_start = rdtsc();
// 写外设寄存器触发中断
writel(1, TRIGGER_REG);
}用rdtsc指令读取时间戳计数器，精度在纳秒级。但要注意：rdtsc在多核上可能不同步。我建议在同一个核上触发和测量，或者用rdtscp指令带上核心ID。
好了，关于Intel平台的中断处理机制，核心就是这些。APIC/IOAPIC的配置、优先级管理、嵌套屏蔽、延迟优化，每一个都是实时系统的关键。下次遇到中断相关的问题，你可以先从这几个角度排查。嗯，中断搞定了，实时系统就成功了一半。