NTB EEPROM设置与跨节点数据传输

NTB EEPROM设置与跨节点数据传输

双控双活系统中除了需要监测系统状态的心跳之外，还需要能够跨节点传输数据的通道。PCIE非透明桥（NTB）由于其基于标准的PCIE规范，软件依赖少，速度快，配置简便，受到许多人的青睐。基于PCIE NTB进行跨节点数据传输的原理很简单，如下图所示意：

较之于普通的PCIE/PCI设备的配置空间寄存器，NTB上多了bar2/3,bar4/bar5的地址转换寄存器，本地节点发送过来的命中bar2/bar3或者bar4/bar5的TLP的地址高位会转换成相应的地址转换寄存器里的值，然后转发到对方节点。

在本人最近的一次NTB调试过程中，发现数据能从link port端写到virtual port一侧指定的内存地址中去，并且virtual port这侧能从指定的地址读回link port端写回的数据；但是类似的程序交换在virtual port端和link port端上执行时，发现virtual port端能把数据写到link port端，并且从link port端读回的数据和之前写的数据一致，但是link port端却无法从指定的地址读回期望的数据。

为了分析这一问题，笔者首先用GDB跟踪了代码，没有发现程序逻辑上的问题；然后把两端的程序统一到一个文件中，用不同的输入参数控制是做远程读写还是本地读写，重新测试，还是能够看到同样的现象。正在百思不得其解的时候，突然想起了地址转换的原理，脑海里浮现出地址转换的过程：

首先，判断NT接受到的TLP的地址是否命中它对应的Bar，在我所使用的实际例子当中，实际用到了Bar3/Bar2组成的一个64 bit的基地址。检查之后，确定CPU是往这一地址访问数据；

接着，检查地址转换寄存器里的值是否是期望的值。正确的值应该是跨节点要访问的内存在所在它所在节点的总线地址，在intel x86的体系结构当中，这个总线地址就是内存的物理地址。检查这个寄存器的值也没问题，如下它的值是：0x0d6d80007800003

[root@localhost bin]#  lspci -xxxxx -s 06:00.0 | grep "c30"

c30: 00 00 00 00 0b 00 01 b7 03 00 80 07 00 00 80 6d

[root@localhost bin]#  lspci -xxxxx -s 06:00.0 | grep "c40"

c40:0d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

既然基地址寄存器和地址转换寄存器都没有问题，那问题到底在哪里呢？Request ID的值也设置过，也没有问题。到底问题出在哪呢？

正在百思不得其解的时候，想起来了地址转换寄存器的高位的位段长短也是由setup寄存器设置的，setup寄存器最高为直到从高到低位出现的第一个不为1的bit作为mask，后面的bit全为0，与地址转换寄存器中的值进行与就得到转换后的地址高位。

根据上面的转换方式，发现在virtual port这一侧，Bar3/Bar2的setup寄存器是0xfffffffe00000000，因此转换后的地址是：

0xfffffffe00000000 & 0x0d6d80007800003 = 0x0d6d800000000000。实际我使用的地址窗口只有2M，因此期望转换后地址的高位应是：0x0d6d80007800000。这就难怪为什么总感觉数据能写道对方节点去，但在对方期望的地址总是读不会指望的数据。因此setup的寄存器必须改成：0xffffffffffe000000。按照上面的设置，利用下面命令重新设置下寄存器的值：　

[root@localhost bin]# setpci -s 06:00.0 d8.l=0xffffffff

接着进行测试，完全通过。继续分析为何setup寄存器出现问题，原来它的值是由NTB　EEPROM初始化的，在我维护的EEPROM固件的一个中间颁布中出现问题导致f变成了e。

这次给我的教训就是一定要深刻理解NTB数据传输的原理，只有对它进行地址转换的过程和相关寄存器了然于胸，才能刨根到底。

本文转自存储之厨51CTO博客，原文链接：http://blog.51cto.com/xiamachao/1750055 ，如需转载请自行联系原作者