从你的描述和提供的崩溃日志来看，这个问题的核心是自定义PEBS NMI处理模块未适配KVM虚拟化环境，导致在客户机内核态访问了未映射的地址。下面是具体的分析和排查方向：

核心问题定位 #

崩溃日志里的关键信息能帮我们缩小范围：

• #PF: supervisor read access in user mode：内核态（supervisor）尝试访问一个未存在的页面，且访问行为被标记为用户模式下的操作
• RIP: 0033:0x55bd4855cd56：错误触发点指向用户空间代码段，但实际触发页错误的地址CR2: ffff9c122e8a1038是客户机内核地址，说明NMI处理流程中出现了地址空间混淆或错误的内存访问逻辑

排查与解决方向 #

1. 检查NMI处理中的地址空间切换逻辑 #

在KVM虚拟化环境下，客户机的内核地址空间是被虚拟出来的：

• 当NMI触发时，KVM会先切换到宿主机的页表（CR3寄存器）处理事件，如果你的模块直接访问客户机内存，必须先切换回客户机的CR3
• 请验证你的NMI处理函数中，是否正确保存了触发NMI时的客户机CR3值，在访问客户机内存前切换到该页表，处理完成后再恢复原CR3

2. 适配KVM对PEBS的虚拟化限制 #

Intel PEBS在虚拟化场景下有特殊的处理规则：

• KVM通过VMCS寄存器控制客户机对PEBS的访问权限，直接在客户机内核中修改IA32_PERF_GLOBAL_CTRL等硬件寄存器，可能导致无效的地址映射
• 检查你的模块是否正确通过KVM的虚拟化接口配置PEBS，而非直接操作硬件寄存器；同时确保PEBS缓冲区分配在KVM允许的客户机内存区域

3. 验证SMEP/SMAP的实际生效状态 #

虽然你尝试了启用/禁用这些选项，但KVM可能会强制或过滤相关设置：

• 在客户机中执行grep -E 'smep|smap' /proc/cpuinfo，确认这些特性是否真正生效
• 如果启用了SMEP，确保你的模块在NMI处理时没有错误地访问用户空间地址；使用内核提供的__user/__kernel宏标记内存访问类型，避免越界

4. 排查NMI处理的栈空间与上下文破坏 #

NMI处理有独立的栈空间，虚拟机环境下栈资源可能更受限：

• 检查你的NMI处理函数是否使用了过大的栈上变量，导致栈溢出破坏上下文，进而引发错误地址访问
• 尽量将大的数据结构改为动态分配（kmalloc/vmalloc），减少栈空间占用

5. 验证崩溃地址的页表映射 #

针对触发页错误的地址ffff9c122e8a1038：

• 在客户机正常运行时，计算该地址对应的物理页号，执行cat /proc/kpageflags | grep -C1 <物理页号>，查看该页是否存在且已映射
• 在你的模块中添加页表检查逻辑，访问该地址前先确认页表项是否有效

调试建议 #

• 使用QEMU调试参数启动虚拟机：qemu-system-x86_64 -s -S <其他参数>，然后用GDB连接target remote :1234，在你的NMI处理函数处设置断点，跟踪到触发页错误的具体代码行
• 在NMI处理函数中添加日志，记录触发时的CR3、要访问的内存地址等关键信息，对比客户机正常运行时的上下文

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