自己做网站 服务器,网站备案实名认证,嵌入式软件开发哪家好,建设带数据搜索的网站安全之安全(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 一致性
如…安全之安全(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 一致性
如果一个设备的事务窥探snoopPE 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 生成子流 IDSubstreamID。建议 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 ServiceITS隔离了 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 空间由转换表中的配置决定。
