PCIe扫盲:Memory & IO 地址空间/基地址寄存器详解/Base & Limit寄存器详解

写在前面

笔者在工作中需要包个 PCIe wrapper，正在努力飞快学习 PCIe ing.
本文系转载，略做格式调整与增加解释（使用斜体表示），转自:
http://blog.chinaaet.com/justlxy/p/5100053328

转载正文

Memory & IO 地址空间

早期的PC中，所有的IO设备（除了存储设备之外的设备）的内部存储或者寄存器都只能通过IO地址空间进行访问。但是这种方式局限性很大，而且效率低，于是乎，软件开发者和硬件厂商都不能忍了……然后一种新的东西就出来了——MMIO。

MMIO，即Memory Mapped IO，也就是说把这些IO设备中的内部存储和寄存器都映射到统一的存储地址空间（Memory Address Space）中。

但是，为了兼容一些之前开发的软件，PCIe仍然支持IO地址空间，只是建议在新开发的软件中采用MMIO。

注：PCIe Spec中明确指出，IO地址空间只是为了兼容早期的PCI设备（Legacy Device），在新设计中都应当使用MMIO，因为IO地址空间可能会被新版本的PCI Spec所抛弃。

IO地址空间的大小是4GB（32bits），而MMIO则取决于处理器（和操作系统），并且由处理器进行统一分配管理。

如下图所示，PCIe总线中有两种MMIO：P-MMIO和NP-MMIO。

P-MMIO，即可预取的MMIO（Prefetchable MMIO）；

NP-MMIO，即不可预取的MMIO（Non-Prefetchable MMIO）。其中P-MMIO读取数据并不会改变数据的值。

注：P-MMIO和NP-MMIO主要是为了兼容早期的PCI设备，因为PCIe请求中明确包含了每次的传输的大小（Transfer Size），而PCI并没有这些信息。

基地址寄存器（BAR）详解

基地址寄存器（BAR）在配置空间（Configuration Space）中的位置如下图所示：

其中Type0 Header最多有6个BAR，而Type1 Header最多有两个BAR。

这就意味着，对于Endpoint来说，最多可以拥有6个不同的地址空间。但是实际应用中基本上不会用到6个，通常1~3个BAR比较常见。

主要注意的是，如果某个设备的BAR没有被全部使用，则对应的BAR应被硬件全被设置为0，并且告知软件这些BAR是不可以操作的。

对于被使用的BAR来说，其部分低比特位是不可以被软件操作的，只有其高比特位才可以被软件操作。

而这些不可操作的低比特决定了当前BAR支持的操作类型和可申请的地址空间的大小。

一旦BAR的值确定了（Have been programmed），其指定范围内的当前设备中的内部寄存器（或内部存储空间）就可以被访问了。当该设备确认某一个请求（Request）中的地址在自己的BAR的范围内，便会接受这请求。

下面用几个简单的例子来熟悉BAR的机制：

例1. 32-bit Memory Address Space Request

如下图所示，请求一个4KB的NP-MMIO一般需要以下三个步骤：

Step1：如图中（1）所示，未初始化的BAR的低比特（11~4）都是0，高比特（31~12）都是不确定的值。

所谓初始化，就是系统（软件）向整个BAR都写1，来确定BAR的可操作的最低位是哪一位。

当前可操作的最低位为12，因此当前BAR可申请的（最小）地址空间大小为4KB（2^12）。如果可操作的最低位为20，则该BAR可申请的（最小）地址空间大小为1MB（2^20）。

Step2：完成初始化（写1操作）之后，软件便开始读取BAR的值，来确定每一个BAR对应的地址空间大小和类型。其中操作的类型一般由最低四位所决定，具体如上图右侧部分所示。

Step3：最后一步是，软件向BAR的高比特写入地址空间的起始地址（Start Address）。如图中所示，为0xF9000000。

例2. 64-bit Memory Address Space Request

下面是一个申请64MB P-MMIO地址空间的例子，由于采用的是64-bit的地址，因此需要两个BAR。具体如下图所示：

例3. IO Address Space Request

下面是一个申请IO地址空间的例子，如下图所示：

注：需要特别注意的是，软件对BAR的检测与操作（Evaluating）必须是顺序执行的，即先BAR0，然后BAR1，……，直到BAR5。当软件检测到那些被硬件设置为全0的BAR，则认为这个BAR没有被使用。

注：无论是PCI还是PCIe，都没有明确规定，第一个使用的BAR必须是BAR0。事实上，只要设计者原意，完全可以将BAR4作为第一个BAR，并将BAR0~BAR3都设置为不使用。

Base & Limit寄存器详解

上一篇文章介绍了Type0型配置空间Header中的BAR的作用和用法，但是PCIe中的桥设备（Switch和Root中的P2P）又是如何判断某一请求（Request）是否属于自己或者自己的分支下的设备的呢？这实际上是通过Type1型配置空间Header中的Base和Limit寄存器来实现的，这篇文章来进行简单地介绍一下。

Base和Limit寄存器在Type1 Header中的位置如下图所示：

Base和Limit寄存器分别确定了其所有分支下设备（The device that live beneath this bridge）的地址的起始和结束地址。根据请求类型的不同，分别对应不同的Limit&Base组合：

· Prefetchable Memory Space（P-MMIO）
· Non- Prefetchable Memory Space（NP-MMIO）
· IO Space（IO）

一旦该桥分支下面的任意设备的BAR发生改变，该桥的Base&Limit寄存器也需要做出对应的改变。

下面以一个简单的例子，来分析一下：

如上图所示，连接到Switch的PortB上的PCIe Endpoint分别配置了NP-MMIO、P-MMIO和IO空间。下面来简单地分析一下PortB的Header中的Base & Limit 寄存器。

P-MMIO Base & Limit

NP-MMIO Base & Limit

需要注意的是，Endpoint的需要的NP-MMIO的大小明明只有4KB，PortB的Header却给其1MB的空间（最小1MB），也就是说剩余的空间都将会被浪费掉，并且其他的Endpoint都将无法使用这一空间。