I8042KeyboardInterruptService为何在多核系统中出现键盘中断丢失？

Question

在多核系统中，`I8042KeyboardInterruptService`（Windows内核中处理i8042键盘控制器中断的ISR）常出现键盘中断丢失问题。根本原因在于：i8042控制器本质是**单线程、非重入式硬件**，其状态寄存器（如Status Register的IBF/OBF位）和数据端口存在严格时序依赖；而多核环境下，多个CPU核心可能并发进入该ISR（尤其在未正确配置中断亲和性或未禁用其他核心上的同级IRQ共享时），导致竞态——例如Core 0读取状态后被抢占，Core 1重复读取并清空输出缓冲区，致使Core 0后续读取返回无效数据或跳过按键。此外，Windows早期版本（如Win7/Server 2008 R2）的i8042驱动未对`KINTERRUPT`对象启用`SYNCHRONIZE_ACCESS`标志，且未强制绑定至BSP（Boot Processor），加剧了跨核中断分发与服务的不一致性。典型现象为：高负载下按住Shift/Ctrl键偶发失灵、组合键响应延迟或漏报。

Answer 1

```html

一、现象层：可复现的用户态症状与日志线索

• 高负载下长按 Shift/Ctrl/Alt 键时出现“键卡顿”或“松开后仍被识别为按下”（Ghost Key）
• 组合键（如 Ctrl+Alt+Del、Win+L）偶发无响应，需多次触发才生效
• Windows Event Log 中频繁出现 Event ID 10016（DCOM 权限警告） 伴随 Event ID 11（i8042prt 驱动重置端口）
• 使用 !irp -a 和 !kirq 在 WinDbg 中观察到多个 CPU 核心同时处于 I8042KeyboardInterruptService 函数栈帧内

二、驱动层：i8042prt.sys 的 ISR 并发执行模型缺陷

Windows 内核中 i8042prt.sys 的中断服务例程（ISR）未做跨核序列化保护。关键事实如下：

属性	Win7/2008 R2 行为	Win10 1809+ 改进
KINTERRUPT.SynchronizeAccess	❌ 未启用（默认 FALSE）	✅ 强制设为 TRUE
IRQ Affinity Mask	⚠️ 默认允许所有 CPU	✅ 自动绑定至 BSP 或首个可用核心
Port I/O 序列保护	❌ 仅依赖 KeAcquireSpinLockAtDpcLevel（粒度粗）	✅ 增加 InterlockedCompareExchange 状态校验

三、硬件层：i8042 控制器的不可重入性本质

i8042 是一个典型的“状态机式”微控制器，其行为由严格时序定义：

• OBF（Output Buffer Full）位必须在读取数据端口（0x60）前为 1，否则返回垃圾值；
• IBF（Input Buffer Full）位控制命令写入时机，误判将导致控制器锁死；
• 状态寄存器（0x64）与数据端口（0x60）共享同一总线周期窗口 —— 无内存屏障即无顺序保证；
• 硬件不支持原子读-改-写（RMW），无法用 LOCK 前缀同步。

四、系统层：APIC 中断分发与亲和性配置失配

现代多核平台通过 IOAPIC/LAPIC 分发 IRQ 1（键盘中断），但 Windows 默认策略存在隐患：

1. 若 BIOS 启用 “Legacy IRQ Remapping”，而 OS 未调用 HalRequestIpi 协同屏蔽，会导致 IRQ 1 被广播至多个 CPU；
2. SetThreadAffinityMask 对内核 ISR 无效，必须通过 KeSetTargetProcessorNumberEx + IoConnectInterruptEx 显式约束；
3. 虚拟化环境（如 Hyper-V Gen2 VM）中，i8042 被模拟为合成设备，但中断仍走传统路径，加剧竞态窗口。

五、诊断流程：从现象到根因的五步定位法

graph TD A[用户报告 Shift 键失灵] --> B{是否仅发生于高负载？} B -->|是| C[启用 ETW Kernel Logger：
Kernel-Memory, Interrupts, HAL] B -->|否| D[检查 BIOS 中 “Fast Boot” / “USB Legacy Support” 设置] C --> E[分析 trace 中 ISR 入口时间戳分布：
若多个 CPU 时间差 < 500ns → 确认并发 ISR] E --> F[用 !interrupt -v 查看 KINTERRUPT.Flags：
SYNCHRONIZE_ACCESS == 0 ⇒ 驱动缺陷] F --> G[验证 i8042prt.sys 版本：
6.1.7601.xxxx 为旧版；≥10.0.17763 修复完备]

六、解决方案矩阵：短期规避与长期加固

方案类型	实施方式	适用场景	风险说明
Registry Hotfix	设置 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters\ForceBSP = DWORD:1	Win7/2008 R2 现网应急	可能降低中断响应吞吐，但杜绝跨核竞争
Driver Patch	Hook I8042KeyboardInterruptService，前置插入 KeRaiseIrqlToDpcLevel + 全局自旋锁	定制嵌入式 Windows	需 WHQL 签名，违反微软驱动模型规范
Firmware Fix	UEFI 中禁用 PS/2 emulation，改用 USB HID keyboard（需 BIOS 支持 xHCI PS2 emulation）	新硬件部署	老旧外设（如带 PS/2 接口的 KVM 切换器）不可用

七、深度验证：用 Windbg + Time Travel Debugging（TTD）复现竞态

// 在 TTD trace 中执行：
0: kd> .ttime
Time: 123.456s
0: kd> bp i8042prt!I8042KeyboardInterruptService "dt i8042prt!_I8042_PORT_STATE poi(@rax+0x10); .echo '--- ISR on CPU '; .cpuid; gc"
// 输出将显示多个 CPU 同时命中，且 _I8042_PORT_STATE.OBF 值在不同上下文中不一致

八、演进视角：为何现代 Windows 已基本消除该问题？

• Windows 10 RS5（1809）起，i8042prt.sys 默认启用 SYNCHRONIZE_ACCESS 并强制 IRQ 1 绑定 BSP；
• 引入 KeTryToAcquireQueuedSpinLock 替代传统自旋锁，减少缓存行乒乓（Cache Line Ping-Pong）；
• 内核模式下的 Port I/O 操作增加隐式 MemoryBarrier，确保状态寄存器读取顺序不被编译器/CPU 重排；
• Windows Server 2022 默认禁用 Legacy PS/2 支持，引导用户迁移至 HID-compliant 设备栈。

九、延伸思考：同类问题在其他传统外设中的映射

该问题范式可推广至以下场景：

• serenum.sys（串口枚举）对 16550 UART 的 OBF/THRE 竞态；
• atapi.sys 在 PIO 模式下对 IDE 主/从设备的状态寄存器争用；
• 嵌入式领域中，ARM Cortex-M 的 SYSCON 寄存器组未加 __DMB() 导致的外设配置失效。

十、工程实践建议：面向稳定性的驱动开发守则

1. 所有 Legacy ISA 设备驱动的 ISR 必须启用 SYNCHRONIZE_ACCESS 或显式绑定单核；
2. 涉及 Port I/O 的驱动，应在 DriverEntry 中注册 IoRegisterPlugPlayNotification 监听 IRP_MN_QUERY_RESOURCES，动态适配 ACPI _PRS 返回的 IRQ 属性；
3. 对非原子硬件状态机，采用“状态快照 + 校验重试”机制，而非简单轮询；
4. 构建 CI 流水线时，集成 Driver Verifier 的 IRP Logging 和 Deadlock Detection 模块，覆盖多核压力场景。

```