启用VMX时PS/2 8042复位失效的原因及相关技术疑问

1. VMX启用时8042复位失败的核心原因 #

当CPU处于VMX启用状态（无论根模式还是非根模式），其硬件复位信号的响应逻辑会被VMX架构修改。尽管Intel SDM未直接提及VMX会忽略RESET#引脚信号，但实际行为是：VMX模式下，CPU会拦截外部硬件触发的RESET#信号，不会直接进入原生复位流程。

8042控制器发送的0xfe命令会断言RESET#引脚，但此时CPU处于VMX管控状态，复位信号无法触发原生的硬件复位流程。只有执行VMXOFF退出VMX模式，让CPU回到非虚拟化的原生状态，才能正常接收并响应RESET#信号完成系统重启。

2. INIT中断与8042复位的关联 #

8042的0xfe复位命令通常会触发两类硬件信号：

• 直接断言RESET#引脚，触发CPU冷复位；
• 部分平台会同步发送INIT#中断信号，作为复位前的初始化触发步骤。

VMX启用时，CPU会将INIT#信号视为VM-exit事件，而非直接触发CPU初始化。如果VMM没有显式处理该VM-exit并模拟初始化逻辑，INIT中断就无法生效，进而导致依赖RESET#+INIT#组合的复位流程失败。这正是Linux代码中要求禁用VMX/SVM的原因：确保INIT中断能被原生CPU识别，配合复位信号完成完整重启。

3. Linux的重启策略 #

Linux会根据硬件平台和运行环境选择多种重启方式，并非仅依赖8042：

• 传统PC平台：优先尝试8042复位（向0x64端口写入0xfe），但检测到VMX/SVM启用时，会先执行VMXOFF/SVMDISABLE再执行复位；
• UEFI平台：调用UEFI Runtime Service的ResetSystem()接口，由固件负责完成复位操作；
• 服务器/特殊平台：使用IPMI命令、平台专用复位寄存器或电源管理芯片接口触发复位；
• 虚拟化Guest环境：通过hypercall通知宿主VMM完成重启，不直接操作硬件。

4. 硬件复位CPU的常见方式 #

硬件层面，CPU复位主要通过以下几种触发机制：

• RESET#引脚触发：由主板复位电路（8042控制器、电源管理芯片等）断言，触发冷复位，重置CPU所有寄存器及硬件状态；
• INIT#引脚触发：触发暖复位流程，保留部分内存状态，常与RESET#配合使用；
• SMM模式复位：通过SMI进入系统管理模式后，由固件执行复位操作；
• MSR寄存器写入：部分CPU支持写入特定MSR（如0x194）触发复位；
• 电源管理芯片控制：通过ACPI或平台专属接口，命令电源芯片发送复位信号。

内容的提问来源于stack exchange，提问作者Eric Stdlib