SMMU软件指南之系统架构考虑

安全之安全(security²)博客目录导读

目录

5.1 I/O 一致性

5.2 客户端设备

5.2.1 地址大小

5.2.2 缓存

5.3 PCIe 注意事项

5.3.1 点对点通信

5.3.2 No_snoop

5.3.3 ATS

5.4 StreamID 分配

5.5 MSI

---

本博客介绍与 SMMU 相关的一些系统架构注意事项。

5.1 I/O 一致性

如果一个设备的事务窥探（snoop）PE cache以寻找内存的可缓存区域，那么它与PE cache的I/O是一致的。这可以通过避免缓存维护操作（Cache Maintenance Operation, CMO）来提高性能。设备无需访问外部内存，而 PE 也不会嗅探设备cache。

如果设备与 PE cache保持 I/O 一致性，则不需要对与设备共享的内存进行 CMO。此内存在 CPU 上映射为Inner Write-Back (iWB), Outer Write-back (oWB), and Inner shareable (ISH)。如果设备与 PE 缓存不保持 I/O 一致性，则需要对映射为 iWB-oWB-ISH 的共享内存进行 CMO。

以下类型的 SMMU 访问可以是 I/O 一致的：

• SMMU 发起的事务
        ◦ 翻译表遍历
        ◦ 获取 L1STD、STE、L1CD 和 CD
        ◦ 命令队列、事件队列和 PRI 队列访问
        ◦ MSI 中断写入
• 设备发起的事务
        ◦ 如果SMMU与系统的接口支持I/O一致性，则可以使简单的非一致性设备实现I/O一致性。SMMU 可以重写来自客户端设备的事务的可缓存性和共享性属性，使得输出到互连中的事务能够嗅探 PE 缓存。

SMMU 是否支持发出一致访问由 SMMU_IDR0.COHACC 指示。

【注意】Arm 基础系统架构要求翻译表和配置结构访问支持 I/O 一致性。

为了支持 I/O 一致性访问，SMMU 需要提供正确一致性保证的互连端口。例如，AMBA 互连中的 ACE-Lite 端口可以支持 I/O 一致性访问。

5.2 客户端设备

本节描述了客户端设备的一些要求，包括：
• 地址大小
• 缓存
• 对 PCIe 设备或根端口的要求
• StreamID 分配
• 消息信号中断（Message Signalled Interrupts）

5.2.1 地址大小

SMMU 的架构输入地址大小为 64 位。如果发生以下任一情况：
• 客户端设备输出的地址小于 64 位。
• 客户端设备与 SMMU 输入之间的互连支持的地址小于 64 位。

则较小的地址会以系统特定的方式转换为 64 位的 SMMU 输入地址。SMMU 会对扩展后的 64 位地址执行输入范围检查：
• N 被定义为 VA（虚拟地址）区域的大小，由 CD.T0SZ 或 CD.T1SZ 控制，例如 40 位。
• 如果使用了高字节忽略（Top Byte Ignore），即 CD.TBI0 或 CD.TBI1，则 VA[55:N-1] 的所有位都相同。
• 如果未使用高字节忽略，则 VA[63:N-1] 的所有位都相同。

5.2.2 缓存

连接在 SMMU 后面的设备不能包含与系统其余部分完全一致的缓存，因为嗅探（snoop）与物理缓存行有关，而 SMMU 无法从物理地址（PA）反向转换为虚拟地址（VA）。这些设备可能包含不支持硬件一致性的缓存，此类缓存必须通过软件维护。

然而，包含通过 SMMU 使用 ATS（地址转换服务）填充的 TLB 的客户端设备可以保持完全一致的物理地址缓存，利用 TLB 将内部地址转换为物理地址后再进行缓存访问。SMMU 上游的任何物理地址缓存都必须保持一致性。例如，使用 ATS 来转换虚拟地址和一致性物理地址缓存的 CXL.cache 或 CCIX 客户端设备。

5.3 PCIe 注意事项

在与 PCIe 子系统配合使用时，SMMU 实现必须支持至少完整的 16 位 PCIe 请求者 ID 范围。系统必须确保根端口以一对一或线性方式将 PCI 请求者 ID 生成 StreamID，以便满足 StreamID[15:0] == RequesterID[15:0] 的关系。可以通过串联来自多个 PCI 域（或“段”）的请求者 ID 来构建更大的 StreamID，例如：
• StreamID[17:0] == { pci_rp_id[1:0], pci_bus[7:0], pci_dev[4:0], pci_fn[2:0] }，即 StreamID[17:0] == { pci_domain[1:0], RequesterID[15:0] };

在支持 PASID 的 PCIe 系统中，系统必须确保根端口以一对一方式从 PCI PASID 生成子流 ID（SubstreamID）。建议 SMMU 支持与客户端根端口相同或更少的 PASID 位数，以便软件能够通过 SMMU 检测端到端的子流 ID 功能。这是因为软件可以查看 SMMU_IDR1.SSIDSIZE 寄存器字段来了解有多少位的 PASID 可用。如果根端口支持的位数少于 SMMU_IDR1.SSIDSIZE，则需要在其他地方提供此信息，例如固件表。

Arm 基础系统架构要求如果系统支持 PCIe PASID，则至少支持 16 位 PASID。该支持必须是从根端口到需要 PASID 支持的 SMMU 的完整系统支持。

属于 PCIe 终端设备的流不应被阻塞（stall）。终止(terminate)模型是唯一可行的选择。阻塞 PCIe 事务可能会导致来自 PCIe 终端设备的超时（恢复可能较难），或在某些场景中导致死锁。系统允许出于安全原因实施终止模型。例如，LTI 协议包括 LAFLOW 信号，AXI/ACE-Lite 问题 H 包括 AxMMUFLOW 信号，DTI 协议包括 DTI_TBU_TRANS_REQ.FLOW。所有这些信号和消息均支持 NoStall 模式，可以实施终止模型。如果发生转换错误，即使 SMMU 已为此转换上下文启用了 Stall Faulting，也会在不依赖于 SMMU 软件配置的情况下返回错误响应。

特别地，PCIe 流量不应等待任何 PE 操作，包括清空事件队列或重新启动被阻塞的事务。PCIe通信必须始终向前推进，而不受软件的无限延迟的影响。

5.3.1 点对点通信

PCIe 点对点（P2P）通信允许两个 PCIe 设备在彼此之间直接传输数据，而无需使用主机内存作为临时存储。是否支持通过系统的 P2P 流量取决于系统的具体情况。在支持 PCIe 层级进行 P2P 通信而无需经过 SMMU 的系统中，SMMU 无法隔离 PCIe 设备。为了解决此问题，PCIe 规范包含对 PCIe 访问控制服务（Access Control Services, ACS）的支持：

• 使用 ACS 时，当交换机端口看到对对等交换机端口的请求时，它将 P2P 请求上行传输至根端口进行请求验证，以检查事务是否被允许以对等设备为完成者。
• 根端口决定是否可以将此请求转发至其预期目标设备。
• PCIe 规范指示，此决定借助重定向请求验证逻辑做出。
• SMMU 是唯一可以实施此隔离的代理，因此其扮演了重定向请求验证逻辑的角色。
• 如果 P2P 请求在 SMMU 查找中导致错误响应，则其为 ACS 违规错误。这可能由以下原因之一引起：
        ◦ 请求没有访问目标位置的必要权限。
        ◦ 请求的 VA 没有与请求设备上下文的转换表结构中存在的有效 VA 到 IPA 或 VA 到 PA 转换。
        ◦ 存在配置错误或某些暂时性错误。

5.3.2 No_snoop

PCIe 事务包含一个 No_snoop 属性。如果 PCIe 事务中设置了 No_snoop 属性，则表示允许该事务“退出”硬件缓存一致性。软件缓存一致性确保该访问不会命中缓存，从而允许 I/O 访问避免嗅探缓存。与该事务关联的内存属性必须被替换为 Normal-iNC-oNC-OSH。
No_snoop 的支持取决于系统。如果实现了 No_snoop，则其会将最终访问属性从 Normal 可缓存类型转换为 SMMU 下游的 Normal-iNC-oNC-OSH。

5.3.3 ATS

PCIe 功能可能会认为在地址转换缓存（ATC）中缓存转换是有益的。功能或软件可以考虑以下情况：
• 在较长时间内频繁访问的内存地址范围，或相关的缓冲区内容具有较高的更新速率。
• 例如，以下内存地址范围：
        ◦ 工作和完成队列结构
        ◦ 低延迟通信的数据缓冲区
        ◦ 图形帧缓冲区
        ◦ 用于缓存特定功能内容的主机内存

5.4 StreamID 分配

系统设计人员为请求方分配一个唯一的 StreamID 以输入 SMMU。StreamID 命名空间是每个 SMMU 单独的，因此 StreamID 必须在每个 SMMU 内唯一。
在具有 RME DA 扩展的 SMMU 的机密计算架构（CCA）系统中，设备接口可以在可信或非可信模式下操作：

• 在非可信模式下操作时，SEC_SID = 非安全（Non-secure）
• 在可信模式下操作时，SEC_SID = 领域（Realm）

在这两种模式下，提供给 SMMU 的 StreamID 是相同的。例如，请求者 ID 为 0x100 的 PCIe 设备将以 StreamID 0x100 输入到 SMMU，但由于设备配置的更改，SEC_SID 可能会改变。
【注意】：在 Linux 中，SMMUv3 驱动程序不支持多个设备在相同 SMMU 下使用相同的 StreamID。
有关 PCIe 设备 StreamID 生成，请参见 PCIe 注意事项。

由于与物理设备关联的 StreamID 是系统特定的，系统软件通过固件描述将 StreamID 提供给操作系统。ACPI 表和设备树均可将 StreamID 呈现给每个设备的操作系统。

5.5 MSI

在 Arm GICv3 架构中，GIC 中断翻译服务（Interrupt Translation Service，ITS）隔离了 MSIs。参见《区域特定外设中断（LPls） Arm 通用中断控制器 v3 和 v4》。

ITS 接收包含 EventID 和 DeviceID 输入的 MSI 写入信息，并使用这些信息选择正确的 PE 或虚拟 PE 和 IRQ 号以触发中断。

ITS 需要 DeviceID 输入来隔离中断源。Arm 基础系统架构提供了如何从 StreamID 生成 DeviceID 的规则，该 StreamID 通过 SMMU 传递。最简单的方法来实现相同粒度的中断源的区分和
SMMU DMA区分是从设备的SMMU StreamID生成设备的DeviceID。这种关系越简单，对高级软件和固件系统描述越有利。DeviceID 可以一对一地或通过简单线性偏移从 StreamID 派生。

ITS 寄存器映射提供一个包含一个 MSI 目标寄存器的页面。此页面可以通过 SMMU 安全地暴露给设备，例如：

• 当设备分配给用户空间驱动程序时，该页面可以通过一级转换映射到设备，以便用户空间驱动程序用 VA 目标编程 MSIs。
• 当设备分配给虚拟机（VM）时，该页面可以通过二级转换映射到设备，使得guest操作系统使用 IPA 目标编程 MSIs。

在非 CCA 系统中，设备总是以 SEC_SID = 非安全（Non-secure）的方式向 SMMU 提供 MSIs。
在具有 RME DA 扩展的 CCA 系统中，兼容 TEE 设备接口安全协议（TDISP）的设备可以以两种方式发送 MSIs：

• 如果通过配置空间的 MSI 功能配置 MSI，则它以 T = 0 发送到主 SoC，并因此以 SEC_SID = 非安全的方式呈现给 SMMU。
• 如果通过设备接口的受保护 MMIO 区域中的 MSI-X 功能配置 MSI，则它以 T = 1 发送到主 SoC，并因此以 SEC_SID = 领域的方式呈现给 SMMU。

来自单个设备接口的 MSIs 不论使用哪种 MSI 机制，都会以相同的 DeviceID 呈现给 GIC ITS 接口。MSI 的目标 PA 空间由转换表中的配置决定。