3. QNX 中断处理流程：从硬件触发到任务恢复

QNX 实时操作系统的中断处理采用 微内核 + 进程外代理 架构，中断延迟极短且可预测。一个完整的中断生命周期包含五个阶段：中断到来 → 内核态中断入口 → 中断分发 → ISR 执行 → 退出中断。下面逐阶段拆解时序与数据流。

3.1 中断到来：硬件信号与 CPU 响应

当外设（如网卡、串口、定时器）产生中断请求时，信号通过中断控制器（如 x86 的 APIC 或 ARM 的 GIC）路由到 CPU 核心。CPU 在完成当前指令后，检查中断标志位，若中断未被屏蔽则进入响应流程。

3.2 内核态中断入口：向量表与上下文保存

CPU 根据中断号从 中断向量表（IVT/IDT） 中取出对应的入口地址，跳转到 QNX 内核预置的 interrupt_entry 汇编例程。该例程执行以下操作：

1. 保存通用寄存器（rax, rbx, rcx, rdx, rsi, rdi, r8–r15 等）到内核栈。
2. 保存浮点/向量寄存器（若当前任务使用了 FPU）。
3. 读取中断号 并压栈，作为后续分发函数的参数。
4. 切换内核栈指针 到当前 CPU 的中断专用栈（IST），防止用户栈溢出影响内核。
5. 调用 C 语言分发函数 intr_dispatch()。

; QNX 中断入口汇编伪代码（x86-64）
interrupt_entry:
    push    rax
    push    rbx
    push    rcx
    push    rdx
    push    rsi
    push    rdi
    push    r8
    push    r9
    push    r10
    push    r11
    ; 保存中断号（由硬件或中断控制器提供）
    mov     rax, [rsp + 8*11]   ; 从栈中获取中断向量号
    push    rax
    ; 切换到中断栈
    mov     rsp, [per_cpu_ist]
    ; 调用 C 分发函数
    call    intr_dispatch

3.3 中断分发：查找 ISR 链表

intr_dispatch() 函数根据中断号，在内核维护的 中断服务例程（ISR）注册表 中查找对应的处理链表。QNX 支持多个 ISR 共享同一中断号（共享中断），链表按优先级排序。

// 中断分发核心逻辑（简化）
void intr_dispatch(uint32_t vector) {
    struct isr_entry *entry = isr_table[vector].head;
    while (entry) {
        if (entry->dev->status & DEV_ACTIVE) {
            // 调用 ISR，传入设备上下文
            int handled = entry->handler(entry->arg);
            if (handled) {
                // 标记中断已处理，退出循环
                entry->dev->handled = 1;
                break;
            }
        }
        entry = entry->next;
    }
    // 若未处理，记录统计信息
    if (!entry) {
        spurious_interrupt_count[vector]++;
    }
}

3.4 ISR 执行：快速响应与延迟处理

ISR（Interrupt Service Routine）在 中断上下文中 执行，必须遵守以下约束：

• 不可阻塞：不能调用 sleep()、mutex_lock() 等阻塞 API。
• 不可执行文件 I/O：文件系统可能依赖同一中断控制器。
• 执行时间极短：典型 ISR 应在 10–50 µs 内完成。
• 仅做必要操作：读取硬件状态寄存器、清除中断标志、将数据放入预分配缓冲区。

QNX 提供 中断线程（Interrupt Thread） 机制，允许 ISR 将耗时工作委托给一个高优先级线程，ISR 本身只做最小处理：

// ISR 委托模式示例
int my_isr(void *arg) {
    struct my_dev *dev = (struct my_dev *)arg;
    // 1. 读取硬件状态
    uint32_t status = in32(dev->base + STATUS_REG);
    // 2. 清除中断标志
    out32(dev->base + CLEAR_REG, 1);
    // 3. 将数据放入环形缓冲区
    ring_buffer_push(dev->rb, status);
    // 4. 唤醒中断线程处理数据
    InterruptSendEvent(dev->intr_thread_id);
    return 1; // 表示已处理
}

3.5 退出中断：恢复上下文与任务调度

ISR 返回后，内核执行 intr_exit 汇编例程，完成以下步骤：

1. 检查是否需要抢占：若 ISR 唤醒了更高优先级的线程，设置 重新调度标志。
2. 恢复通用寄存器：从内核栈弹出保存的寄存器值。
3. 恢复浮点/向量寄存器（若之前保存）。
4. 执行 iretq 指令：从栈中恢复 RIP、CS、RFLAGS，返回被中断的用户或内核代码。
5. 调度检查：若重新调度标志置位，在返回后立即触发 reschedule()，切换到更高优先级的任务。

; QNX 中断退出汇编伪代码（x86-64）
intr_exit:
    ; 检查是否需要重新调度
    test    byte [per_cpu_resched_flag], 1
    jnz     .do_resched
    ; 恢复通用寄存器
    pop     rax
    pop     rbx
    pop     rcx
    pop     rdx
    pop     rsi
    pop     rdi
    pop     r8
    pop     r9
    pop     r10
    pop     r11
    ; 恢复中断号参数
    add     rsp, 8
    ; 返回被中断点
    iretq
.do_resched:
    ; 保存当前上下文，调用调度器
    call    reschedule
    jmp     intr_exit

3.6 完整中断处理流程 SVG 架构图

下图展示了从硬件中断信号到任务恢复的完整数据流与各阶段时序占比：

3.7 中断处理关键参数对比表

3.8 中断处理数据流总结

QNX 中断处理流程的设计哲学是 最小化中断上下文停留时间，将耗时操作推迟到线程上下文中。整个流程可概括为：

• 硬件层：中断控制器 → CPU 核心 → 向量表跳转
• 内核层：汇编入口 → C 分发 → ISR 链表遍历 → 回调执行
• 线程层：ISR 唤醒中断线程 → 线程处理数据 → 同步到应用

这种分层设计保证了 QNX 在 高中断频率（10 kHz+） 场景下仍能保持 微秒级确定性，是航空航天、工业控制、汽车电子等实时系统的首选方案。