这看起来是PCIe事务层的读请求重排序/缓存一致性问题——我之前在开发自定义PCIe端点设备时碰到过几乎一模一样的情况，结合你描述的现象（跨64位字访问出问题、重启后触发、读延迟8次），可以从以下几个方向分析原因和修复：

核心原因分析 #

1. PCIe读事务的重排序与缓存特性
   Linux内核的MMIO读操作会被CPU侧的PCIe根复合体做优化，比如合并同地址空间的请求、利用读缓存提升性能。但当访问跨64位字的偏移时，根复合体可能会对读请求进行重排序，而Cyclone V的PCIe端点核心如果没有开启读响应排序功能，就会导致响应和请求不匹配，出现读返回旧值的延迟现象。

2. CPU侧MMIO读缓存的残留状态
   重启后，CPU的PCIe根复合体可能保留了之前的读缓存状态（尤其是当BAR空间没有配置正确的非缓存/非窥探属性时），导致读操作返回缓存的旧值，直到缓存被多次访问刷新（你看到的8次延迟刚好对应缓存行大小或事务队列深度）。

3. Cyclone V PCIe端点的事务队列配置不足
   Cyclone V的PCIe硬核有Tx/Rx事务队列，如果队列深度配置过小，或者没有开启读响应的顺序匹配功能，当多个读请求并发到达时，设备侧返回的响应可能被根复合体错误地关联到旧的请求上，导致读值错位。

具体修复步骤 #

1. Linux驱动侧调整MMIO访问属性 #

• 使用非缓存映射：在驱动中映射BAR0时，务必使用ioremap_nocache而非普通的ioremap，确保每次读操作直接访问设备，绕过CPU缓存：

  void __iomem *bar0_base = ioremap_nocache(pci_resource_start(pdev, 0), pci_resource_len(pdev, 0));
  

• 添加内存屏障：如果已经用了非缓存映射，在每次读操作前添加内存屏障，强制刷新PCIe链路的读缓冲区：

  mb(); // x86架构使用mb()，其他架构可对应使用dmb()/rmb()
  uint8_t val = readb(bar0_base + offset);
  

• 预读初始化：在驱动probe阶段，对BAR0中所有关键寄存器执行一次预读操作，强制刷新缓存状态：

  // 示例：预读所有需要访问的寄存器偏移
  const uint32_t reg_offsets[] = {A, B, ...};
  for (size_t i = 0; i < ARRAY_SIZE(reg_offsets); i++) {
      readb(bar0_base + reg_offsets[i]);
  }
  

2. Cyclone V PCIe端点配置优化 #

• 开启读响应排序：在Quartus的PCIe硬核配置界面，找到「Transaction Ordering」选项，勾选「Read Completion Ordering」，确保设备返回的读响应与请求顺序严格一致。
• 增大事务队列深度：将Tx Completion队列深度调整为16或32（根据Cyclone V硬核文档的推荐值），避免队列溢出导致响应乱序或丢失。
• 严格地址对齐：确保设备侧的寄存器按64位对齐，Linux侧的访问偏移也严格对齐到64位边界——非对齐的PCIe事务可能触发根复合体的拆分请求，增加乱序风险。
• Tag匹配校验：在FPGA逻辑中，给每个读请求分配唯一的Tag值，返回响应时携带相同的Tag，确保根复合体能正确匹配请求与响应。

3. 重启后的链路重置 #

• 在驱动初始化时，执行一次PCI设备的软重置，确保PCIe链路状态完全重置：

  pci_reset_function(pdev);
  

• 或者通过setpci命令手动重置（调试阶段可用）：

  setpci -s <bus:dev.fn> 0x44.b=0x40 # 触发PCIe功能重置，具体寄存器需参考设备手册
  

验证方法 #

• 用mmiotrace重新捕获读操作，确认请求的事务属性是否带有「No Snoop」标记；
• 在FPGA侧用Signaltap监控PCIe Tx Completion包，检查Tag值是否与请求匹配，响应顺序是否正确；
• 使用setpci查看PCI配置空间，确认BAR0的缓存属性是否正确设置：

  setpci -s <bus:dev.fn> 0x0c.l # 查看Cache Line Size，建议设置为64字节对齐
  

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