ARMv8A Hypervisor启用Stage-2 MMU后PCI引发MMU故障排查

1. PCI映射高物理地址是否合理？ #

合理。ARMv8-A架构支持最大48位物理地址空间（具体取决于硬件实现，QEMU的Cortex-A53通常支持40位物理地址，上限为0x1_0000_00000），0x40_1000_0000远低于该上限，属于合法的物理地址范围。PCIe的BAR地址本身就允许分配到高地址区域，只要模拟器/硬件支持该地址范围的解码，完全符合架构规范。

2. 故障调试思路 #

解析ESR故障码 #

先拆解ESR_EL1值0x960000004的具体含义：

• 异常类别（EC，bits[31:26]）：0x19，表示来自EL1的64位数据Abort
• 数据故障状态码（DFSC，bits[9:0]）：0x04，表示Stage-2翻译故障（Level 0页表未命中），说明EL1访问的虚拟地址对应的物理地址，在Hypervisor的Stage-2页表中没有有效映射。

逐步调试步骤 #

• 验证Stage-2页表项的正确性

  • 检查你添加的页表项是否完全覆盖0x40_1000_0000到0x40_2000_0000（256MB）的地址范围，确认起始地址、长度计算无错误
  • 核对页表项的内存属性：PCI配置空间需要设备内存类型，需对应Hypervisor中MAIR_EL2的配置（通常为Device-nGnRnE或Device-nGnRE，属性值分别为0x00或0x04）
  • 检查页表项的权限：确保EL1拥有读写权限（Stage-2页表的AP字段需设置为EL1 RW，即AP[1:0] = 0b01）
  • 用GDB手动遍历Hypervisor的Stage-2页表，确认0x40_1000_0000对应的页表项存在且属性正确

• 核对虚拟地址到物理地址的映射关系

  • 故障虚拟地址为0xffff800020000000，需确认Linux内核中该虚拟地址对应的物理地址确实是0x40_1000_0000
  • 通过GDB查看EL1的Stage-1页表，或读取内核的ioremap映射表，确认虚拟地址与物理地址的映射关系正确，且与DTB中声明的PCI地址范围一致

• 检查DTB配置的正确性

  • 确认DTB中PCI控制器的reg属性是否正确声明了0x40_1000_0000起始、0x10000000长度的物理地址范围
  • 检查ranges、interrupt-map等属性是否存在配置错误，避免内核错误解析PCI地址空间
  • 对比QEMU默认的PCI地址分配，确认0x40_1000_0000未被其他设备占用

• 验证Hypervisor的Stage-2页表加载与TLB刷新

  • 确认Hypervisor在启用Stage-2 MMU时，你添加的页表项已正确加载，未被其他代码覆盖
  • 在Hypervisor中设置断点，当EL1访问目标物理地址时，检查Stage-2页表的实时状态
  • 确认修改Stage-2页表后，已执行TLBI VMALLE1IS等指令完成EL1的TLB刷新，避免旧的无效映射残留

• 最小化场景测试

  • 简化DTB配置，只保留PCI控制器和基础BAR映射，移除无关设备，排查是否是其他配置导致的冲突
  • 尝试将PCI设备映射到低物理地址区域（如0x10000000），验证是否能正常工作，排除地址范围本身的兼容性问题

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