听起来你遇到的这个问题挺典型的——物理机上自定义代码能正常捕获指令计数器相关的PMI，但在开启-cpu host的KVM虚拟机里，计数器能正常递增却触发不了中断，而Linux内核本身却能正常工作。结合我之前排查类似问题的经验，大概率是你的代码漏掉了KVM PMU虚拟化特有的配置步骤，或者KVM环境的PMU权限/支持没完全打开，给你梳理几个关键排查方向：

1. 确认KVM宿主机的PMU虚拟化支持状态 #

KVM对Intel PMU的虚拟化需要宿主机内核和QEMU的双重支持，先从这里入手：

• 检查宿主机内核是否开启了CONFIG_KVM_INTEL_PMU：执行zcat /proc/config.gz | grep CONFIG_KVM_INTEL_PMU，输出应该是CONFIG_KVM_INTEL_PMU=y
• 查看KVM模块的PMU启用状态：检查/sys/module/kvm_intel/parameters/enable_pmu的内容，如果是N，执行echo Y > /sys/module/kvm_intel/parameters/enable_pmu临时开启（要永久生效的话，需要在grub参数里添加kvm_intel.enable_pmu=1）
• 尝试给QEMU启动命令添加显式的PMU开启参数：把-cpu host改成-cpu host,+pmu——虽然host应该继承宿主机的CPU特性，但部分旧版本QEMU/KVM可能默认限制了PMU暴露，显式添加能规避这个问题

2. 检查虚拟机内的PMU功能暴露与中断配置 #

即使宿主机支持，虚拟机里的CPUID和中断配置也可能影响PMI触发：

• 验证虚拟机是否正确识别PMU：安装cpuid工具后执行cpuid -1 | grep PMU，应该能看到Haswell对应的PMU特性（比如PMU version: 3）
• 确认LAPIC中断掩码：PMI是通过本地APIC触发的，你的代码要确保对应中断向量没有被LAPIC的掩码寄存器屏蔽。可以对比物理机和虚拟机里的LAPIC寄存器状态，看是否有差异
• 如果你是直接读写MSR寄存器配置PMU：要确保PERF_GLOBAL_CTRL MSR（地址0x38F）里已经启用了目标计数器，并且对应计数器的控制MSR里设置了INT位（允许溢出触发中断）

3. 用户态代码的权限与接口选择 #

如果你的代码是运行在用户态，直接读写MSR可能在KVM里受限：

• KVM通常会拦截用户态对PMU相关MSR的直接读写，推荐使用Linux的perf_event_open系统调用替代——这也是内核本身处理PMI的标准路径，能自动适配KVM的虚拟化环境
• 如果你坚持直接操作MSR，需要确保进程拥有CAP_SYS_RAWIO权限（可以通过sudo运行代码，或者给二进制文件添加CAP_SYS_RAWIO能力）

4. 排除计数器溢出配置的差异 #

物理机和KVM的PMU计数器在溢出阈值处理上可能有细微差别：

• 检查代码中计数器初始值的设置：Haswell的PMU计数器是64位的，要确保你正确设置了64位的初始值（比如不要只写低32位），溢出条件是计数器从0xFFFFFFFFFFFFFFFF回绕到0
• 可以尝试降低溢出阈值（比如设置一个很小的初始值），看是否能触发PMI——如果小阈值能触发，说明是原阈值的计算在KVM里有问题

快速验证小技巧 #

先在虚拟机里用perf工具做个测试：执行perf record -e instructions ls，然后用perf report查看采样结果。如果perf能正常捕获指令计数的PMI，说明KVM的PMU虚拟化完全正常，问题肯定出在你的代码配置上；如果perf也无法捕获，那就是KVM环境的PMU支持没配置到位，回到第一步排查。

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