企业官网建设流程全解析

简介：面向嵌入式、芯片与 SOC 底层开发者的 SMMU 系统学习资料，围绕 ARM 架构下 System MMU 的定位与价值展开，适合具备 MMU、页表与虚拟化基础、希望系统掌握 SMMU 原理与安全应用的中高级读者。内容从 SMMU 的发展脉络与使用场景切入，覆盖非连续地址映射、32 位 Master 访问 64 位空间、访问空间限制、用户态驱动安全以及设备虚拟化等典型用途，并进一步讲解 TBU 与 TCU 硬件组成、StreamID、STE 表结构、Context Descriptor、两级地址翻译流程及安全与非安全寄存器差异，帮助读者建立从概念到硬件原理的完整认知。资源包共 1 个文件，为 1 份 PDF 文档，大小约 1.53MB，便于离线阅读与查阅。已有 252 人学习，适合结合 armv9、TrustZone 与 TEE 安全开发场景对照理解 SMMU 在系统中的实际作用。

1. 到底什么是 SMMU：给“外设”配一个专属内存管家

如果你写过驱动，大概遇到过一个让人头大的场景：网卡、显示控制器、摄像头这类外设要直接读写内存，它们拿到的地址往往是一串物理地址，写死在代码里，换个芯片就得重来。更麻烦的是，这些外设一旦拿到总线控制权，理论上能访问整块内存，写错一个地址就可能把内核数据踩烂。SMMU 就是为解决这类问题而生的。

SMMU 全称 System Memory Management Unit，中文常译作“系统内存管理单元”。一句话定义：它是挂在总线上、专门替各类外设（也就是 Master）做地址翻译和访问权限检查的硬件模块。你可以把它理解成“给外设用的 MMU”——CPU 有自己的 MMU 把虚拟地址翻译成物理地址，SMMU 则让 DMA、VPU、DPU 这些外设也能用上虚拟地址，并且只能访问被允许的那片区域。搞懂它，你才能看懂现代 ARM SOC 里设备访问内存的完整链路，这也是它在 armv8、armv9 芯片和嵌入式安全领域反复被提起的原因。

2. SMMU 为什么存在：四个绕不开的现实需求

2.1 让外设用上“连续”的虚拟地址

现在的系统里，几乎没人会为某个外设预留一大段连续的物理内存。物理内存被操作系统切得七零八落，而很多外设（尤其是 DMA 引擎）偏偏要求缓冲区地址连续。没有 SMMU 时，软件只能靠“预留连续内存池”这种笨办法，浪费且不灵活。

有了 SMMU，事情就变成：软件给外设分配一段连续的虚拟地址，背后映射到若干零散的物理页。外设只管往这段虚拟地址里写，SMMU 负责把每一笔访问翻译到真正的物理页上。打个比方，这就像快递员只需要记住一个“总收发室”的门牌号，至于包裹最终放进哪个仓库的哪个货架，由收发室统一调度。VPU、DPU 这类需要大块缓冲的模块，正是靠这个机制才不用关心物理内存的碎片化。

2.2 把 32 位外设接进 64 位世界

不少外设至今仍是 32 位寻址能力，只能访问低 4GB 空间。可现代 SOC 的内存往往远大于 4GB，高地址空间对这些外设来说像隔着一堵墙。传统做法是软硬件配合做“内存交换”，把数据搬到低地址再让外设读，实现复杂、性能也吃亏。

SMMU 提供了一条更干净的路：外设发出 32 位地址，SMMU 按页表把它翻译成 64 位物理地址，外设自己完全无感。这相当于给老式设备配了一个“地址翻译官”，它说的方言（32 位）被实时转成通用语言（64 位），访问高地址空间不再是难题。

2.3 给外设的访问范围上锁

这是 SMMU 和安全关系最紧密的一点。一个 Master 挂在总线上，默认能访问的地址空间几乎是全量的。一旦驱动有 bug 或者设备被恶意利用，后果可能是整片内存被读写。SMMU 允许软件为每个外设建立页表，精确规定“你只能访问这一片区域”。

提示：这片允许访问的区域不是写死的，而是 CPU 在建立 SMMU 页表时动态决定的，所以可以随进程、随场景调整。

用户态驱动是另一个典型场景。把设备驱动放到用户态能省去频繁的内核态切换，但用户态代码直接操作设备，万一访问到内核空间就是安全事故。SMMU 在这里充当“护栏”，把设备的可达范围限制在驱动自己的缓冲区里，越界访问直接被硬件拦下。

2.4 支撑设备虚拟化与 TrustZone

设备虚拟化有模拟、半虚拟化、直通几种路子。直通（Pass-through）性能最好、软件改动最小，但前提是能把设备访问的地址空间隔离开——这正是 SMMU 的活。它让一台虚拟机里的设备只能碰自己的内存，互不干扰。

在安全层面，一些本身不支持 TrustZone 的 Master，可以借助 SMMU 获得类似的安全隔离能力：安全侧的页表能把访问导向安全内存，非安全侧则被挡在门外。这也是 TEE、ATF、TF-A 这些安全组件讨论 SMMU 配置的原因。

3. SMMU 的内部构造：TBU、TCU 与两级查表

3.1 从 MMU 到 SMMU：结构上的对应关系

学过 MMU 的人都知道它由 TLB 加地址翻译逻辑组成。SMMU 的结构可以类比，但拆得更细：它由 TBU（Translation Buffer Unit）和 TCU（Translation Control Unit）组成。TBU 里含有 TLB，负责缓存最近用过的翻译结果；TCU 负责真正的页表遍历和地址翻译控制。两者之间通过 DTI 协议连接，这是 SMMU 内部的总线协议。

一个 SMMU 里可以放多个 TBU，比如多个 ACE-Lite TBU 或 LTI TBU，分别对接不同类型的外设接口。这种设计的好处是：不同外设的翻译请求可以并行处理，TLB 缓存也能就近放置，减少延迟。

3.2 StreamID：每个外设的“身份证号”

总线上挂着一堆 Master，SMMU 怎么知道这次访问是谁发出来的？靠 StreamID。每个外设发起访问时会带上自己的 StreamID，SMMU 用它去查对应的配置表。你可以把 StreamID 理解成外设的身份证号，SMMU 凭号办事，不同号对应不同的翻译规则和权限。

3.3 STE 表：从 StreamID 找到翻译配置

有了 StreamID，下一步是找到这个外设的配置项，也就是 STE（Stream Table Entry）。STE 表的组织方式有两种：Linear Stream Table 和 Multi-level Stream Table，具体用哪种由寄存器 STRTAB_BASE_CFG 里的比特位决定。

线性表最直观：StreamID 的数值直接作为下标，查到对应的 STE，查询一步到位，适合 StreamID 取值范围不大的场景。多级表则像查字典先查部首再查字，用多级索引换取更省内存的表结构，适合 StreamID 空间很大的情况。

一个 STE 之下还可以挂多个 Context Descriptor（CD）。这里的关键类比是：一个 Context Descriptor 就相当于 MMU 系统里的 TTBRx 加 TCR 寄存器——它规定了这一路翻译用哪张页表、按什么格式翻译。而 Stage 1 翻译所用的页表格式，和 CPU MMU 的页表格式是一致的，理论上 Core 的 MMU 和 SMMU 可以共用同一套页表。

3.4 两阶段翻译与安全属性

SMMU 的地址翻译同样分 Stage 1 和 Stage 2，和 MMU 一致。Stage 1 负责虚拟地址到中间物理地址的转换，Stage 2 再转到最终物理地址，这种两阶段结构正是虚拟化场景的基础。

安全属性上有一个必须记牢的规则：SMMU 有 Secure STE 和 Non-secure STE 之分。Secure STE 后面的页表可以把访问翻译到安全内存，也可以翻译到非安全内存；而 Non-secure STE 只能翻译到非安全内存。这和 MMU 描述符里的 NS 比特是同一个道理——安全侧可以向下兼容，非安全侧不能越界向上。

3.5 两套寄存器：软件眼里的“两个 SMMU”

SMMU 的寄存器都是 memory-map 的。特别之处在于它有两套寄存器：一套给安全 Master 用，一套给非安全 Master 用。带 S 前缀的（如 SMMU_S_STRTAB_BASE、SMMU_S_STRTAB_BASE_CFG）是安全侧，不带 S 的（如 SMMU_STRTAB_BASE、SMMU_STRTAB_BASE_CFG）是非安全侧。

注意，这不是 banked 寄存器——它们的名字不同，memory-map 地址也不同。所以从软件视角看，硬件明明只有一块 SMMU，却像是有两个独立的 SMMU。配置时如果搞混了安全和非安全的基址寄存器，页表就会建到错误的一侧，症状往往是设备访问莫名失败，排查起来相当费劲。

4. 常见误区与易混概念：别把 SMMU 和 MMU 混为一谈

4.1 误区一：SMMU 就是“外设版的 MMU”，所以完全一样

易混点在于两者确实共享页表格式和两阶段翻译模型，很多人就以为可以照搬 MMU 的经验。为什么混？因为教材讲 MMU 时只讲“一个核一套页表”，而 SMMU 要服务多个 Master。

怎么区分：MMU 只给一个 core 用，页表基址寄存器就那么几个；SMMU 要给多个 Master 用，每个 Master 对应不同的表，所以才引入了 STE 这一层。记住这个层级关系——StreamID 找 STE，STE 找 Context Descriptor，Context Descriptor 才等价于 TTBRx 加 TCR。多出来的 STE 层，就是 SMMU 区别于 MMU 的核心。

4.2 误区二：一个 STE 只能对应一个 Context Descriptor

易混点来自“一般也就只用一个”的工程习惯。实际上一个 STE 可以指向多个 Context Descriptor，只是多数场景下确实只用其中一个。为什么混？因为看到示例配置里只有一个 CD，就以为硬件限制如此。

怎么区分：看需求。如果同一个外设需要在不同地址空间之间切换（比如多进程共享设备），多 CD 就有意义；如果只是单一映射，一个 CD 足够。判断依据是软件是否需要为同一个 StreamID 准备多套翻译规则。

4.3 误区三：Secure STE 和 Non-secure STE 只是命名不同

易混点在于两者结构相似，容易以为权限也一样。为什么混？因为寄存器名字只差一个 S，看起来像对称设计。

怎么区分：权限是不对称的。Secure STE 的翻译目标可以是安全内存也可以是非安全内存；Non-secure STE 只能指向非安全内存。这跟 MMU 描述符的 NS 比特逻辑一致。配置安全设备时如果错用了 Non-secure STE，访问安全内存会被拦，表现为设备功能异常而非明显报错，属于典型的“玄学”问题。

4.4 误区四：SMMU 只和虚拟化有关

易混点是把 SMMU 当成虚拟化专属硬件。为什么混？因为设备直通是它最出名的用途之一。

怎么区分：虚拟化只是它的应用之一。访问非连续地址、32 位转 64 位、限制 Master 访问范围、用户态驱动隔离，这些都不涉及虚拟机。判断标准很简单：只要涉及“外设访问内存需要翻译或限权”，SMMU 就可能在场。

4.5 误区五：配好页表就万事大吉，TLB 不用管

易混点在于把 SMMU 当成纯查表硬件，忽略了 TBU 里的 TLB 缓存。为什么混？因为页表配置是显式可见的，TLB 是隐式的。

怎么区分：页表改了之后，旧的翻译结果可能还留在 TLB 里，必须做相应的无效化操作才能生效。这和 CPU MMU 的 TLB 维护是同一类血泪经验——改了映射不刷 TLB，设备读到的还是旧地址，现象诡异且难复现。

5. 什么时候该用 SMMU，什么时候别硬上

先说该用的场景。第一，外设需要大块缓冲区而物理内存碎片化严重时，用 SMMU 做虚拟连续映射，比预留连续内存池干净得多。第二，系统里存在 32 位 Master 却要访问 4GB 以上地址空间时，SMMU 的地址扩展几乎是标配方案。第三，任何需要限制外设访问范围的场合——用户态驱动、多租户环境、安全隔离——SMMU 都是硬件层面的护栏。第四，设备直通虚拟化和给不支持 TrustZone 的 Master 补安全能力，也离不开它。

再说别硬上的情况。如果系统里外设访问模式极其简单、地址空间小、也没有安全隔离需求，引入 SMMU 意味着多一层页表维护和 TLB 管理，配置复杂度和调试成本都会上升，收益却有限。另外，SMMU 的页表建立和失效维护需要软件配合，如果团队对两阶段翻译和安全/非安全寄存器划分不熟，配错的风险不低——前面说的安全基址寄存器搞混、Non-secure STE 指向安全内存，都是实际会翻车的地方。

一个具体的判断例子：某图像处理 Demo 里，一个 32 位 VPU 要处理超过 4GB 的帧缓冲，同时驱动跑在用户态。这里 SMMU 是刚需——既解决地址扩展，又限制 VPU 只能碰自己的缓冲。反过来，如果只是一个地址空间很小、驱动在内核态、无隔离需求的小外设，硬加 SMMU 配置反而增加维护负担。

配置层面有个容易忽略的细节：改完 STE 或 CD 指向的页表后，必须让对应的 TLB 失效，否则设备仍按旧映射访问。伪代码大致如下：

/* 更新某个 StreamID 对应的 STE 配置后 */ update_ste(stream_id, new_ste); /* 使该 StreamID 相关的 TLB 条目失效，确保新配置生效 */ smmu_tlb_invalidate(stream_id); /* 必要时加内存屏障，保证配置写入对硬件可见 */ dsb(sy);

这里的stream_id指定要刷新的外设身份，smmu_tlb_invalidate负责清掉旧翻译缓存，dsb保证写入顺序。少了这一步，新页表形同虚设，设备行为会停留在旧映射上，排查时极容易怀疑人生。

从那以后我每次动 SMMU 配置，都强制走一遍“改表—刷 TLB—加屏障”的流程，再小的改动也不省。希望这些概念梳理能帮到你，少走几段弯路。

本文还有配套的精品资源，点击获取