PCI段(域)如何与多个主机桥(或根桥)相关？
Zih*_*han 5 cpu cpu-architecture pci-bus pci pci-e
我试图了解PCI段(域)如何与多个主机桥相关联？
有人说多个PCI域对应多个主机桥,但有人说它意味着在一个主机桥下有多个根桥.我很困惑,我在PCI SIG基本规范中找不到太多有用的信息.
我想知道
(1)假设我在MCFG中设置了3个PCI域,我是否有3个主机桥连接3个CPU和总线,或者我有3个根桥支持3倍总线但是在一个CPU中共享一个公共主机桥？
(2)如果我有多个主桥(或根桥),这些桥是否共用一个共同的南桥(例如,ICH9),或者它们是分开的？
我是初学者,谷歌并没有解决我的问题.如果有人能给我一些线索,我将不胜感激.
Mar*_*oom 15
使用的措辞令人困惑.
我将尝试用PCI和PCI Express技术的简短而不完整的摘要来修复我的术语.
跳到最后一节阅读答案.
PCI
在常规PCI总线(从此以后PCI)是围绕一个设计总线拓扑:共享总线被用于所有的设备建立连接.
为了创建更复杂的层次结构,某些设备可以作为网桥运行:桥接器将PCI总线连接到另一个,辅助,总线.
辅助总线可以是另一个PCI总线(该设备称为PCI到PCI桥,因此是前向P2P)或不同类型的总线(例如,PCI到ISA桥).
这将创建表单的拓扑:
_____ _______
----------| P2P |--------| P2ISA |------------- PCI BUS 0
??|?? ???|???
-------------|---------------+----------------- ISA BUS 0
|
-------------+--------------------------------- PCI BUS 1
非正式地,每个PCI总线称为PCI段.
在上图中,显示了两个段(PCI BUS 0和PCI BUS 1).
PCI定义了三种类型的事务:内存,IO和配置.
假设前两个是必需的知识.
第三个用于访问每个设备的配置地址空间(CAS); 在此CAS中,可以对设备进行元配置.
例如,它在系统内存地址空间中的映射位置.
为了访问设备的CAS,设备必须是可寻址的.
在电气方面,PCI总线段中的每个PCI插槽(集成或不集成)都是有线的,以创建由三部分组成的寻址方案:设备(0-31),功能(0-7),寄存器(0-255) .
每个设备最多可以有七个逻辑功能,每个功能的CAS为256字节.
总线编号被添加到上面的三元组中,以唯一地标识整个总线拓扑内的设备(而不仅仅是在总线段内).
这个四元组称为ID地址.
重要的是要注意这些ID地址由软件分配(但对于设备部分,由布线固定).
它们是合乎逻辑的,但是,建议从根开始按顺序对总线进行编号.
CPU本身不生成PCI事务,需要主机桥.
它是一个桥(概念上是主机到PCI桥),允许CPU执行PCI事务.
例如,在x86情况下,主机桥将未由其他代理(例如,内存,内存映射的CPU组件,传统设备等)回收的任何内存写入或IO写入传递到PCI总线.
为了产生CAS交易,在x86 CPU写入IO端口0xcf8和0xcfc(第一包含ID地址,所述第二数据,以读/写).
CPU可以拥有多个主机桥,但没有什么能阻止它,尽管它非常罕见.
更有可能的是,系统可以拥有多个CPU,并且每个系统都集成了主机桥,系统可以拥有多个主机桥.
对于PCI,每个主机桥建立一个PCI域:一组总线段.
一个PCI域的主要特征是,它是从其他PCI域分离:一个事务不被域之间路由必需的.
操作系统可以根据需要分配每个PCI域的总线编号,它可以重用总线编号或按顺序分配它们:
NON OVERLAPPING | OVERLAPPING
|
Host-to-PCI Host-to-PCI | Host-to-PCI Host-to-PCI
bridge 0 bridge 1 | bridge 0 bridge 1
|
| | | | |
| | | | |
BUS 0 | BUS 2 | | BUS 0 | BUS 0 |
| | | | | | | | |
+------+ +------+ | +------+ +------+
| | | | | | | | |
| | | | | | | | |
| BUS 1 | BUS 3 | | BUS 1 | BUS 1
不幸的是,PCI域这个词在Linux内核中也有意义,它用于为每个主机桥编号.
就PCI而言,这是有效的,但随着PCI express的引入,这会让人感到困惑,因为PCI express有自己的名称"Host Bridge number"(即PCI段组),术语PCI域表示下游链路PCI Express根端口.
PCI Express
在PCI Express总线(从此以后的PCIe)是围绕一个点至点的拓扑结构:设备仅连接到另一设备.
为了保持软件兼容性,广泛使用虚拟P2P桥接器.
虽然PCI总线的基本组件是设备和桥接器,但PCIe的基本组件是设备和交换机.
从软件的角度来看,没有任何改变(但是对于添加的新功能)并且以相同的方式枚举总线:使用设备和桥接器.
PCIe交换机是设备之间的基本粘合剂,它有n个 下游端口.
在内部,交换机具有PCI总线段,对于每个端口,在内部总线段中创建虚拟P2P桥(虚拟形容词存在,因为每个P2P仅响应CAS事务,这足以用于PCI兼容软件).
每个下游端口都是PCIe链路.
PCIe链路被视为PCI总线段; 这可以检查交换机是否具有每个下游端口的P2P网桥(总共有1 + n个 PCI总线段用于交换机).
交换机还有一个端口:上游端口.
它就像下游端口,但它使用减法解码,就像网络交换机一样,它用于接收来自"逻辑外部网络"的流量并路由未知目的地.
因此,交换机需要1 + N + 1个PCI段总线.
设备直接连接到交换机.
在PCI情况下,桥接器将CPU连接到PCI子系统,因此期望交换机将CPU连接到PCIe子系统是合乎逻辑的.PCI复合根(PCR)
的情况确实如此.
PCR基本上是一个具有重要转折的交换机:每个端口都建立一个新的PCI域.
这意味着不需要将流量从端口1路由到端口2(当然,当有交换机时).如前所述,这会产生Linux术语的转变,因为Linux为每个主机桥或PCR分配域号,而根据规范,每个PCR都有多个域.
长话短说:同一个词,不同的含义.
PCIe规范使用单词PCI segment group来定义每个PCR的编号(简单地说,PCI段组是每个PCR的扩展CAS机制的基址,因此存在本地映射的一对一).
由于它们的隔离特性,PCR的端口称为PCIe根端口.
注意
术语根桥不存在于规范中,我只能在UEFI根桥IO规范中找到它作为主机桥和PCR的总称(因为它们具有相似的职责).
主机桥也名为Host Adapter.
最后你的问题
(1)假设我在MCFG中设置了3个PCI域,我是否有3个主机桥连接3个CPU和总线,或者我有3个根桥支持3倍总线但是在一个CPU中共享一个公共主机桥？
如果您有3个PCI域,则可以使用3个主机桥接端口或3个PCIe根端口.
如果通过PCI域你的意思是PCI总线,就PCI总线段而言(无论它们是否隔离),那么你可以使用单个主机桥/ PCR处理具有3个总线的拓扑或多个主机桥/ PCR处理3辆公共汽车的组合.
在这种情况下没有特别要求,因为您可以看到可以使用桥接级联总线.
如果您希望总线不被隔离(因此不是PCI域),则需要单个主机桥或单个PCIe根端口.
一组P2P桥(实际或虚拟)将总线连接在一起.
(2)如果我有多个主桥(或根桥),这些桥是否共用一个共同的南桥(例如,ICH9),或者它们是分开的？
几年前桥接平台逐渐消失,我们现在将一个系统代理集成到CPU中,该系统代理暴露了一组PCIe通道(通常为20+)和一个平台控制器集线器(PCH),通过DMI链路连接到CPU.
PCH也可以集成到与CPU相同的插槽中.
从软件的角度来看,PCH暴露了一些似乎来自CPU PCR的通道.
无论如何,如果你有多个主机桥,它们通常位于不同的插座上,但通常只有一个南桥.
但是,这是(并且不是)严格强制性的.
现代的英特尔C620 PCH可以在仅端点模式(EPO)中运行,它不用作主PCH(具有固件和引导职责),而是用作一组PCIe端点.
我们的想法是,主机桥只是将CPU事务转换为PCI事务,这些事务的路由取决于总线拓扑,这本身就是一个非常有创意的话题.
集成此拓扑的组件是另一项创造性任务,最终可以为每个主桥提供专用的芯片,或者同时在所有或甚至两者之间共享(或分区)大型单芯片!
配置空间寻址中的域/段（域往往是 Linux 术语，段是 Windows 和 PCISIG 术语）主要是平台级别的构造。域和段在这个答案中可以互换使用。从逻辑上讲，SEGMENT 是 PCI 系列配置空间寻址机制的 DOMAIN:Bus:Device:Function:Offset 寻址方案中的最高有效选择器（最高有效地址位选择器）。（PCIe、PCI-X、PCI 和后续软件兼容总线互连）。
在 PCI-Express (PCIe) 和更早的规范中，DOMAIN 不会出现在总线（或链路上）或链路事务数据包中。只有 BUS、DEVICE、FUNCTION、OFFSET 出现在事务中或总线上。然而，SEGMENT 确实在基于 SEGMENT:Bus,Dev,Func:OFFSET 配置空间软件地址的逻辑软件如何用于实际创建互连协议数据包 (PCIe) 或总线周期序列 (PCI) 中占有一席之地，该数据包被描述为配置空间事务。在 PCI-Express (PCIe) 规范扩展配置空间访问方法 (ECAM) 中，部分解决了这个问题。其余内容由 PCI 固件规范 3.2 处理（涵盖较新的 PCIe 规范软件要求）。
在现代PCIe中，配置空间访问方法由操作系统的ECAM机制来处理，该机制抽象了这种配置空间访问机制（将CPU内存空间访问指令转变为总线/互连配置空间事务的机制）。操作系统软件将 SEGMENT/DOMAIN 理解为配置空间的 SEGMENT:BUS:DEVICE:FUNC:OFFSET 地址方案中的最高级别（最顶层）逻辑选择器和地址组件。SEGMENT 如何从软件逻辑概念转移到物理硬件实例化以 ECAM 翻译器的形式出现，或者具体来说是平台中存在多个 ECAM 翻译器。ECAM转换器在存储器类型事务和配置空间类型事务之间进行转换。PCIe 规范描述了 SINGLE ECAM 转换器实现如何将目标转换存储器写入或读取中的特定存储器地址位转换为配置空间写入或读取。其工作原理如下：
Address Bits:
11:00 (Offset bits, allows 4K of configuration space per PCIe device)
14:12 Function selection bits.
19:15 Device selection Bits.
27:20 Bus Selection Bits. 1 <= n <= 8 (Maximum of 8 bits, 256 numbers, can be less)
63:28 Base address of the individual ECAM.
实际上没有明确（或根本没有）涵盖的是多个 ECAM 可以存在。一个平台可以设置多个ECAM区域。平台为何要这么做？因为ECAM地址位（8位）的总线选择位余量是有限的，仅允许系统中总共256条总线，这在某些系统上是不够的。
PCI固件规范3.2（2015年1月26日）从软件逻辑角度描述了ECAM。固件规范描述了一种称为 MCFG 表的软件内存结构（存在于 BIOS 保留区域中，供 BIOS 和操作系统进行通信）。MCFG 表描述了平台硬件实现中存在的基于 ECAM 硬件的配置空间周期生成器的一个或多个实例。这些是到配置空间周期事务转换区域的存储器地址空间事务（存储器写入）。例如，ECAM 硬件实现是CPU 实例化以允许软件生成配置空间事务的机制。平台实现（通常由 CPU/芯片组设计指定和限制，但有时也由 BIOS 设计选择决定）允许一定数量的 ECAM 配置空间周期生成器。一个平台必须至少支持一个，然后它才会有一个SEGMENT。但是一个平台可能支持多个ECAM，那么它对于每个支持的ECAM都有一个SEGMENT。MCFG 表保存平台支持的每个 ECAM 的一个配置空间基地址分配结构。单个 SEGMENT 平台将只有一个条目，多 SEGMENT 平台将有多个条目，每个受支持的 ECAM 都有一个条目。每个条目包含（ECAM 区域配置空间周期生成器的）内存基地址、与该 ECAM 相对应的逻辑 SEGMENT 组和总线编号子范围，以及存在于内存中的总线编号子范围（开始和结束）。这个逻辑段。
BIOS 不能仅仅决定它需要大量 ECAM 并描述多个 ECAM 并使用常规内存地址作为“基地址”。硬件实际上必须通过设计将内存地址实例化到配置空间周期生成逻辑，该逻辑锚定到特定地址（有时由 CPU/芯片组设计固定，有时由 CPU/芯片组特定的非标准位置配置在位置方面进行配置） ）在任何一种情况下，BIOS 都会描述存在哪些 ECAM，并且根据设计，描述 ECAM 组配置（或禁用）的一种方式或特定方式，以描述 ECAM 组的配置（或禁用）。系统上激活一个或多个活动 ECAM。此类 BIOS 配置的一部分包括设置可配置的 ECAM、选择启用的数量（如果可配置）、它们将驻留在何处（在什么基地址）、配置哪些芯片组设备对应于哪些 ECAM，以及配置哪些根端口对应和与哪些 ECAM 相关联。一旦 BIOS 内部配置完成，BIOS 必须向操作系统描述这些平台硬件和 BIOS 决策。这是使用 PCI 固件规范定义的 MCFG 表来完成的，该表是 BIOS（固件）到操作系统平台描述定义机制的 ACPI 规范的一部分。
使用 MCFG 表方案，可以拥有并描述多个 ECAM 和多个逻辑 SEGMENT，每个 ECAM 一个。也可能有一个 SEGMENT，它实际上也被分割到多个 ECAM 中。（多个条目，但全部使用相同的 SEGMENT，然后是不重叠的总线编号。）但在多段配置中 MCFG 的典型用途是允许多个段，其中总线编号重复。例如，每个SEGMENT 最多可拥有完整的256 条总线，与另一个SEGMENT 中可能存在的最多256 条总线分开。
三组软件都知道配置空间寻址中的段。BIOS（用于创建 MCFG 表）、操作系统（用于读取 MCFG 表、获取 ECAM 基地址，并通过在正确的偏移处访问正确的 ECAM 来处理逻辑到物理地址转换软件任务）以及最后一个group 是所有其他总线、设备、功能 (BDF) 感知软件。所有软件都必须能够识别 SEGMENT、BUS、DEV、FUNC，而不仅仅是能够识别 Bus、DEV、FUNC。假定 SEGMENT 始终为 0 的软件已损坏。如果您曾经创建过此类软件，那么您应该立即赶回办公桌并修复它，在任何人看到它之前，当然也是在它在产品中发布之前！:-)
平台设计（在硬件ECAM支持和BIOS设计中）可以实现多个ECAM。这样做通常是为了规避仅使用单个 ECAM 时出现的 256 总线总数限制。因为 ECAM 是由 PCISIG 定义的，并且因为该定义围绕总线上的总线数量限制（在事务字段中），所以单个 ECAM 无法为超过 256 条总线实现配置空间生成器。然而，平台CAN和DO实例化多个ECAM区域，并且具有描述具有多个ECAM基地址的多个SEGMENT的MCFG表，这允许平台具有超过256条总总线。（但在以 PCIe 根端口为根的每个 PCIe 设备树中最多只能有 256 条总线，并且共享公共 ECAM 配置空间生成器的所有根端口在一起最多只能有 256 条总线。每个 ECAM 区域最多可以描述 256 条总线在其 DOMAIN (或 SEGMENT) 中。平台系统如何决定将主机根端口（缓存一致域到 PCI/PCIe 域桥）分组到 SEGMENT 中是特定于平台的，并且对芯片组/CPU 设计和 BIOS 配置是任意的。大多数平台是固定的和简单化（通常只有一个 ECAM），有些是灵活的、严格的和可配置的，允许多种解决方案。提供在平台级别使用最大数量的 PCIe 总线数量的解决方案类型是支持每个根端口一个 ECAM。（现在很少有平台这样做，但都应该这样做！）它们是用于描述平台“如何”决定将设备、端点和交换机分组到 SEGMENT 中的两种机制。第一个是前面的-提到了 MCFG 结构，它简单地列出了多个 SEGMENT、它们关联的 ECAM（如果一个 SEGMENT 中的总线范围被分割到多个 ECAM 中，则可能不止一个）以及每个 ECAM 的基地址（或 ECAM 总线号子区域）。这种方法本身通常足以满足许多枚举任务，因为这允许操作系统枚举所有段，找到它们的 ECAM，然后对每个段中的所有设备进行 PCI 总线、设备、功能扫描。但是，还可以使用第二种机制来增强 MCFG 信息，即 ACPI 命名空间中的 _SEG 描述符。ACPI 规范具有通用的平台描述机制，以独立于操作系统的方式描述系统中已知设备的关系，但允许操作系统解析数据并消化平台布局。这种机制称为 ACPI 命名空间。在命名空间内，设备是“对象”，因此通常描述固定并包含在 ACPI 实现系统主板上的 PCIe 端点、PCIe 根端口和 PCIe 交换机。在这个命名空间中，对象出现，并且具有限定符或装饰器。一种这样的装饰器“方法”是 _SEG 方法，它描述了特定对象位于哪个 SEGMENT。这样，内置设备可以分组到特定的 ECAM 访问区域，或者更常见的是，特定的 PCIe ROOT 端口分组到 SEGMENTS（以及关联的 ECAM 访问区域，具有 MCFG 描述的基地址）。此外，可以热添加的设备（并且不是静态存在于主板上）可以描述它们在热插拔时重新创建的段，或者它们在热插拔添加时加入的预先存在的段，以及总线他们实例化的那个段中的数字。这是在命名空间中使用 _CBA 方法装饰器在此类命名空间中描述的根端口对象上完成的，并且它与 _SEG 方法结合使用。_CBA 仅适用于顶级“已知”热插拔元件，例如两个 4 CPU 系统可以动态“加入”到单个 8 CPU 系统中，并且它们各自的 PCIe 根端口元件也因此“加入”新的单一系统，从原始基础 4 CPU 系统的 PCIe 根端口扩展，包括添加的 4 个 CPU 的新的附加 PCIe 根端口。
对于出现在插槽或外部扩展机箱中的 PCIe 交换机，_SEG（或 SEGMENT 值）通常继承自平台中已有的最高级根端口（位于 PCIe 设备树的顶层）。包含该根端口的SEGMENT，也是该根端口下面的所有设备所属的段。
人们经常在较早的资料中读到（在多个 ECAM 发明以及配置空间中的段概念和相关操作系统软件之前），PCIe 枚举是通过扫描总线号、然后是设备号、然后是功能号来完成的。这是不正确的，而且已经过时了。实际上，现代（当前）BIOS 和操作系统实际上是通过逐步扫描 SEGMENT（选择要使用的 ECAM）、然后是总线编号、然后是设备编号、最后是功能编号（在特定 ECAM 内应用偏移量）来进行扫描的。在特定 PCIe 根端口之上和之下生成配置周期（例如，在特定 PCIe 设备树上）。
较旧的“PCI”机制（在为 PCIe 定义增强配置配置空间之前）不知道 SEGMENT。PCI 的较旧 CF8/CFC 配置空间访问机制在受到硬件平台支持时（任何新编写的软件都不应再使用）通常会为仅支持传统 PCI（不支持 PCIe）的传统实施最佳实用解决方案操作系统，旧机制被硬编码到该机制的 SEGMENT 0。这意味着仅支持 PCI 的系统只能访问 SEGMENT 0 中的设备。所有主要操作系统都已支持 PCIe ECAM 增强机制超过 10 年，并且当今软件对 CF8/CFC 机制的任何使用都被认为是过时的过时的、过时的和破碎的，应该被 ECAM 机制的现代使用所取代，至少支持 MCFG 表和多个 ECAM，并且如果操作系统的要求需要，则由 ACPI 规范命名空间 _SEG 和 _CBA 属性进行补充操作系统摄取对象方法信息以实现完全动态热插拔情况。如果操作系统未将 ACPI 热插拔方法用于其他任务，则几乎所有非热插拔情况都可以由 MCFG 单独处理。如果操作系统使用 ACPI 热插拔进行其他设备和命名空间操作，则通常还需要操作系统和 BIOS 对 _SEG 和 _CBA 的支持，以描述设备关联分组的方式生成这些 APCI 命名空间对象SEGMENT，从而支持该设备、根端口或根复合体网桥或设备的配置周期生成的特定 ECAM 硬件。现代软件使用段，只有损坏和不正确的软件才会假设所有设备和网桥都存在于段 0 中。现在这并不总是正确的，并且随着时间的推移越来越不正确。
SEGMENT 分组往往遵循硬件设计中的某些逻辑原理以及设计配置的限制。（但并非总是如此，有时，它只是任意且奇怪的。）例如，在 Intel 8 插槽系统（大型多处理器）上，“本机”一致性实现在大多数情况下往往仅限于 4 个插槽。当供应商构建 8 插槽系统时，通常是通过两组 4 插槽组成，每组通过集群交换机在它们之间的一致互连上连接来完成。这种类型的平台可能会实现两个 PCIe 段，每个 4 个插槽集群一个。但对于平台如何使用多个 SEGMENT 和使用多个 ECAM 没有限制。两个插槽的系统可以实现多个 ECAM，每个 CPU 一个 SEGMENT，以便每个 CPU 最多允许 256 个 PCIe 总线，总共 512 个。如果这样的平台将两个 CPU 的所有根端口映射到单个 SEGMENT（更常见），那么整个平台只能有 256 条总线。优化设计的平台（在 ECAM 硬件资源方面更昂贵）将为系统中的每个根端口提供一个 ECAM，并为平台中的每个根联合体设备提供一个 ECAM。具有 8 个根端口的双 CPU 系统，每个 CPU 上有 4 个，每个 CPU 上有 4 个根复合体，将实现 16 个 SEGMENT，其中 8 个（根端口）每个将支持最大 256 总线，并且 8 个支持根复杂的设备树将实例化足够的总线支持来映射根联合体设备和桥接器。因此，如果在 2048+ 总线的高端提供总线支持，这样一个完全组成的两个插槽系统将支持最多 8*256 + 内置根复合体设备所需的总线。今天设计的任何“真正的”服务器都应该这样设计。我仍在等待看到这款现代的“真正的”英特尔或 AMD 服务器，而不是这些天推出的玩具。
大多数操作系统软件不需要关心“如何”实现 SEGMENT 关联，它们只需要考虑到逻辑 SEGMENT 值是配置空间寻址的一部分（不要只为总线、设备、功能编写代码） ，假设SEGMENT = 0）它必须编码为（SEGMENT，BUS，DEVICE，FUNCTION），除非你想被贴上懒鬼类型，做错事，走捷径的低能儿。支持 SEGMENT 值！它们现在很重要，并且在未来将变得越来越重要，因为总线编号空间面临更大的压力（并且平台由于仅限于单个 SEGMENT 中存在的低级和限制性 256 总线而耗尽了总线编号。单个 SEGMENT限制的发生是因为硬件设计，但它也会因为软件没有为多段平台正确编写和准备而发生。不要成为假设软件创建糟糕的单段（SEGMENT = 0）的人。不要成为那个人！ ) 不要以这种方式编写操作系统软件。不要以这种方式编写 BIOS 软件，不要编写可识别总线、设备、功能，但不可识别段、总线、设备、功能的应用程序。
平台操作系统软件（在 *nix 的内核中，或在 Windows 的 HAL 中）采用 SEGMENT 值，并使用它来选择它将访问哪个 ECAM（例如，它将添加 BDF/偏移内存地址偏移量）到）。然后，它使用总线、设备、功能值来索引该 ECAM 中的较高地址位，最后使用配置空间设备寄存器偏移地址来填充送入 ECAM 配置空间的内存地址的较低部分交易生成器作为其内存地址交易输入。
在 Intel 兼容平台（Intel 和 AMD 等）上，PCI 固件规范和 ACPI 规范描述了 BIOS 如何告诉操作系统（例如 Linux、Windows、FreeBSD）一个 ECAM（单段）或每个 ECAM 的位置。 ECAM（多段）基地址位于内存地址空间中。
SEGMENT 永远不会出现在 PCIe 或 PCI 的总线上。在 PCIe 中，RID（路由标识符）仅对发送方的 Bus# 和 Device/Func# 进行编码。同样，在配置周期中，只有目标的 Bus# 和 Device#/Func# 被编码在下游事务中。如果启用了 ARI（替代路由 ID）模式，Device/Func# 可以在 PCIe 中得到修改处理。但是 SEGMENT 值没有出现（也没有出现在 PCI 总线序列中）。它本质上是一个软件构造，但具有真正的硬件实例化，以平台硬件支持（CPU 和芯片组）的形式支持多个 ECAM（多段）或仅单个 ECAM（单段）。请注意，不同 SEGMENT 中的设备实际上仍然可以进行点对点直接通信。点对点事务使用内存寻址（这是所有段之间的单个全局共享空间，例如，至少在 IOMMU 转换并通过根端口传输之后，所有段仍然共享单个统一内存地址空间，这是潜在的先决条件）进行。位于不同的段）。SEGMENT 可以具有冲突和重复的总线编号空间，但是当它们出现在不同的 SEGMENT 中时，这些空间描述了不同的总线。多ECAM系统实际上可以实现单个共享总线地址空间以及独立的重复总线编号空间。实际上，这种情况很少见，因为系统通常会为单个总线地址空间使用单个 ECAM 和单个 SEGMENT。然而，一些奇怪的硬件可能需要利用单段、多 ECAM、跨多个 ECAM 运行的共享单总线，由于某些奇怪的设计原因（通常是热插拔或动态配置相关），提供最大 256 条有限的总线空间。 .)
一个理论平台，其“芯片组/非核心”组件中有很多内置设备，并且其设计中有两个 CPU 插槽，如果愿意的话，可以实现四段设计。它可以使用两个段将所有内置 CPU 设备放入自己的 SEGMENT（每个 CPU 一个），然后将每个 CPU 的 PCIe 根端口映射到自己的 SEGMENT，同样每个 CPU 都有一个唯一的 SEGMENT，总共 4 个部分。这将允许整个系统中有 4 * 256 = 1024 条总线。
具有相同两个套接字数量的不同理论平台可以将所有 CPU（在本例中只有两个）和所有内置设备以及所有现有根端口的所有设备映射到单个 ECAM，从而映射到单个 SEGMENT。这样的平台只有一个 ECAM，因此整个系统的总线总数将被限制为 256 条（因此，如果平台加载了大量数据，则更有可能耗尽总线数量）复杂的多端点附加卡，带有 PCIe 交换机以支持多设备存在。例如，支持 GPU 卡的前置 AI，或者是否有多个扇出交换机（以增加插槽数量），或者是否有外部 PCIe 交换机该供应商正确使用和支持了扩展器（到外部 PCIe 机箱）。
目前正在设计的“最佳”平台和未来将为每个根端口实施独立的 ECAM，从而允许每个根端口在其设备树中单独支持多达 256 条总线，独立于所有其他根端口。迄今为止，我仍在等待这个平台，一个拥有大量 PCIe 段（对应大量 PCIe 根端口）的平台。此类设计对于可组合 I/O 解决方案、共享内存解决方案、分层内存解决方案、可组合存储解决方案、大型外部 I/O 机箱解决方案、支持 CXL 的加速器等至关重要。换句话说，用于现代计算。当一个平台出来并说它的时钟比上一个平台多 5% 时，我打哈欠。当出现针对根端口 ECAM 的支持时，我会注意到，并且该平台将获得我的金印。
总线数量空间的压力现在正处于临界点，因此在不久的将来可能会使用更多的段（或者如果英特尔和 AMD 关注的话应该如此）。像 CXL（PCIe 软件模型兼容的总线基础设施）这样的技术只会增加单个 SEGMENT 的配置空间总线数量限制的压力（现在 256 条总线已经不多了）。每个交换机内部都使用一条总线，每个链路都使用一条总线，因此大量插槽数、高扇出系统将消耗超过 256 条总线。多段设计现已出现，并将越来越普遍。立即修复您的软件！
看：
PCI Express Base Spec 5.0（或任何早期版本）7.2。PCI Express 增强型配置访问机制 (ECAM) http://www.pcisig.com
PCI 固件规范 3.2（或更高版本）http://www.pcisig.com 4.1.2 MCFG 表说明
ACPI 规范“MCFG”定义 http://uefi.org _SEG（段）ACPI 命名空间描述中的命名空间限定符。
UEFI 规范 http://uefi.org 描述了操作系统如何在具有 UEFI BIOS（启动固件）的现代 UEFI 平台中查找 MCFG 表和所有其他基于 ACPI 的表。