把一块PCIe设备插到机器上驱动一旦加载控制台里就会出现一串类似0xf0200000的地址。接着驱动只靠普通的内存读写指令就让板卡上的寄存器响应了。看起来平平无奇但这里藏着一个非常硬核的问题CPU发出去的地址凭什么会跑到PCIe设备头上设备又是怎么知道“这段地址归我管”的这篇文章就把这条链路从头拆到尾。我会从三个地址域的差异讲起再讲设备如何通过BAR宣告自己需要多大空间、系统如何分配地址并打开RC窗口最后用命令、伪代码和一段最小驱动程序把一次MMIO映射完整地“抓住”。适合驱动开发新手、BSP移植工程师以及所有想搞懂lspci输出里Memory at xxx到底在说什么的人。1. 为什么需要“内存映射”三个地址域与一次访存的完整旅程1.1 CPU域、PCI域与设备域三个世界各说各话要理解PCI内存映射第一步是忘掉“地址就是地址”这个直觉。一个PCIe系统里的地址至少有三个不同的“世界观”。CPU物理地址空间CPU看到的世界也是最熟悉的那个。系统内存、BIOS/固件、各类内存映射的外设寄存器都排在这张地址表上。PCI设备的BAR一旦被分配了某个物理地址区间也相当于在这个世界里拿到了一段门牌号。第二个世界是PCI域。根复合体RC看到的世界。RC是CPU和PCIe总线之间的桥梁它手里握着若干“窗口”只有落在窗口范围内的地址才会被翻译成PCIe总线上的Memory TLP事务层包。窗口以外的地址RC要么忽略要么直接返回错误。第三个世界是设备域。设备自己内部实现的那一小块地址空间也就是BAR对应的寄存器堆。设备并不关心CPU那边到底怎么编址它只关心一件事主机桥发来的地址是否和自己BAR里的地址匹配。这三个世界之间的对应关系就是“映射”的本质。在常见x86平台上CPU域和PCI域几乎是直接对应的RC看到哪个地址CPU那边的物理地址就是哪个。但在很多嵌入式SoC上并不是这样——SoC内部的地址翻译逻辑会把CPU侧的地址重新映射到PCI侧这也就是设备树里ranges属性存在的原因。后面实操章节我再补这部分。1.2 一次MMIO读取是如何完成的假设驱动执行了这么一句代码value readl(0xf0200000);CPU会把这个当成一次普通的物理内存读取向地址总线发出0xf0200000。接下来发生的事情才是PCI内存映射最核心的环节地址越过各级缓存和一致性协议来到了根复合体。根复合体用0xf0200000和自己的MMIO窗口比较发现它落入了某个PCIe下游端口对应的地址窗口。RC把这个地址封装成一个PCIe Memory Read TLP根据设备编号送到对应的PCIe链路。设备收到TLP后把自己的BAR地址和TLP里的地址比对。命中后根据地址偏移读取内部寄存器把数据放进Completion with Data TLP。RC把返回的数据整理好交回给CPU。CPU根本感知不到这中间走过了一条PCIe总线它只知道“内存读取完成了”。整个链路对CPU完全透明这也是内存映射这个名字的由来设备寄存器被映射进了CPU的物理地址空间访问它和访问内存条在指令层面没有任何区别只是最终目的地不一样。用生活里的事情打个比方你拨打公司前台的总机号码铃却在某个工位上响起来。号码还是那个号码接电话的人换了。CPU发出的地址还是那个地址应答者从内存条换成了PCIe设备。1.3 为什么不用IO端口而用内存映射早年的PC设备大量使用IO端口映射驱动用in/out指令访问一小片IO space空间。这样做有历史原因但缺点也明显IO地址空间太小x86上只有64KB访问路径特殊每次访问开销明显而且不太适合现代高速设备的高带宽寄存器读写需求。内存映射这种方式之所以最终成为绝对主流是因为它把设备访问“统一”成了普通内存访问。CPU不用再为外设专门走一套访存指令缓存一致性、乱序执行、虚拟内存等机制也能直接参与进来硬件上省掉了一整套特殊访存逻辑。当然代价也存在。MMIO区域为了防止编译器把两次读写合并、防止缓存污染寄存器现场通常被标记为“不可缓存、不可合并、设备内存”语义。这也是为什么驱动里ioremap出来的地址和普通内存的缓存策略完全不一样。不是内核故意折腾你是硬件寄存器根本不能走普通缓存那一套否则你写一个寄存器再读回来很可能读到的是CPU缓存里的旧值。2. BAR机制详解设备如何告诉系统自己需要多大“房间”2.1 配置空间里的六个BAR长什么样每张PCI/PCIe设备卡在配置空间里都有一段标准区域用来描述自己。其中偏移0x10开始定义了最多6个BARBase Address Register每个BAR占32位。当设备需要64位物理地址时会连续占用两个BAR槽位低32位放在前一个BAR高32位放在后一个。以PCIe为例一次枚举时系统会读每个BAR的当前值用来判断设备“声明”了多少片地址空间。如果某个BAR未被实现读回来的值通常是0。这里需要点明一个容易被忽略的事实BAR的数量和宽度都是硬件设计阶段就固定下来的。软件不能“增加”一个BAR只能读取并使用已有的。这也是为什么有些设备只有2个BAR而有些显卡会用满6个BAR甚至还要靠Resizable BAR机制在系统启动后申请调整大小。2.2 BAR里的位域约定一个32位内存BAR的布局是这样的位含义说明bit0空间类型0内存空间1IO空间bit1地址宽度仅内存BAR有效032位164位bit2预取属性仅内存BAR有效1可预取Prefetchablebit3~31基地址设备响应地址的高位部分低地址位被内部硬连为0这里最容易被问住的是对齐规则BAR里的基地址永远是“对齐到自身大小”的。也就是说如果一个设备需要4KB空间那它BAR的bit3~bit31里低12位必然为0如果需要1MB空间低20位必然为0。这不是什么软件约定而是硬件实现的自然结果。设备内部就是拿一组地址比较器去比较地址高位是否等于BAR里保存的基地址。你给设备写进去一个没对齐的地址它也没有足够多的低地址位去精确区分每个偏移自然无法正常工作。预取属性同样影响很大。系统会把可预取的BAR分配到更适合大块连续读写的地址区域这类区域往往不会被严格限制在4GB以下可以和系统内存一样享受更高的缓存和预取策略。不可预取的寄存器区域则必须避免读操作产生副作用因此被分配到更保守的地址窗口。2.3 “写1读回”探测法为什么这招有效正因为BAR的高位是可写的地址位而低位被硬件固化为0或特定值系统才有办法在不知道设备规格的情况下仅凭读写BAR就探测出设备需要多大的地址空间。探测算法异常简单保存BAR的当前值。向BAR写入0xFFFFFFFF。读回BAR值。恢复BAR的原始值。把读回值和0xFFFFFFF0做按位与再取反加1就得到设备要求的空间大小。举例某设备BAR0当前值是0x00000000。写入0xFFFFFFFF后设备把“自己不需要的地址位”强制写回0读回值是0xFFF00000。低4位是类型位屏蔽掉以后得到有效值0xFFF00000。对它取反加一~(0xFFF00000) 1 0x00100000也就是1MB。设备要求BAR0映射1MB地址空间并且这1MB必须1MB对齐。为什么写0xFFFFFFFF有效因为设备内部那些地址比较线是有限的。软件写入全1后凡是设备不支持的地址位硬件根本就没有对应的存储/比较逻辑去保留读回时自然恢复为0。这等于设备在用硬件回答一个问题“你有多少根地址线”这个技巧在PCI枚举阶段被无数次使用。现代系统里的固件和操作系统都是靠这一套读写探针来动态决定设备地址的。所以BAR是双向的它既是设备向系统提出的“空间申请”也是系统给设备分配地址后的“登记处”。3. 枚举、分配与RC窗口谁把BAR地址“贴”到CPU空间3.1 PCI枚举的本质是分配“门牌号”设备插上电以后BAR里并不是出厂就写好了最终地址很多设备默认BAR值就是0。必须由系统在枚举阶段扫描每一条总线、每一个设备、每一个功能逐个读取BAR的空间需求然后在CPU物理地址空间里寻找空闲区域把计算好的基地址写回BAR。这个过程的本质就是系统在给每个设备发门牌号。先扫描到设备读取它的Vendor ID/Device ID确认存在。对每一个BAR做“写1读回”探测算出设备需要多大空间。把所有设备的空间需求放在一起按地址对齐大小排序。在物理地址空间里找没有被内存、ACPI、其他外设占用的空档。把选好的基地址写回BAR同时配置PCIe桥的地址窗口。你看这时候才真正完成了“内存映射”最关键的一步设备知道自己要响应哪个地址了系统也知道这段地址归谁了。后续CPU访问这段区域RC才能把事务正确转发给对应设备。如果这一步出了问题后面驱动写得再对也没用。这也是为什么很多“驱动加载成功但操作寄存器就崩”的问题最终都追溯到BAR地址没有正确分配。3.2 RC窗口与转发条件地址写进BAR只解决了一半问题。另一半是RC必须知道“这段地址应该往哪个PCIe端口送”。根复合体内部维护着多组地址窗口最常见的几类窗口类型作用典型地址范围MMIO 32位窗口转发32位BAR的Memory读写通常位于4GB以下MMIO 64位窗口转发64位BAR的Memory读写通常位于4GB以上IO窗口转发IO BAR的IO访问64KB的IO空间内配置窗口ECAM转发配置空间访问x86上的MMCONFIG区域RC拿到一个地址后要做的事情类似于查一张路由表把地址和各个窗口逐一比较命中哪个就发往哪个下游设备都不命中则作为“不支持的请求”处理。对CPU来说后果往往是从该地址读回全是0xFFFFFFFF在某些平台上甚至直接触发机器检查异常。这里有个常见误区很多人以为只要BAR写对了CPU就能访问设备。实际上如果BAR被分配到某个RC窗口之外比如固件没有开启Above 4G解码却把64位BAR放到了4GB以上RC根本不会往下发这个事务。设备在那边等半天CPU这边只会看到全F。所以排查MMIO问题时永远要同时看两边设备这边的BAR是否写对了RC那边的窗口是否打开了。3.3 为什么4GB以下是PCI设备的“传统保留区”熟悉装机的人都知道老机器上4GB内存经常只能识别到3.25GB左右剩下的空间变成了“PCI空洞”。这个空洞不是浪费而是系统给PCI设备保留的地址区。原因是历史包袱32位CPU物理地址空间只有4GB可用的内存还有一部分要留给BIOS、ACPI等系统资源剩下的一小段自然就成了设备BAR的落脚点。RC在出厂设计时通常也会默认把一批地址范围预留给MMIO避免设备BAR和内存条抢地址。到了64位时代4GB的限制已经不存在了但“4GB以下保留PCI空洞”的兼容性设计仍然保留。这就是为什么现代BIOS/UEFI里有一个Above 4G Decoding开关打开以后RC会额外开放一个4GB以上的64位MMIO窗口让大容量BAR的设备地址分配到高位空间去从而把4GB以下的空洞留给老设备和兼容性场景。做服务端硬件的人应该对这个开关不陌生插多张GPU的机器不打开Above 4G有些卡会因为MMIO空间不足而异常这时光是分配BAR就够系统忙活半天。4. 实操从命令行和驱动里把一个MMIO映射“抓住”4.1 用lspci与内核接口查看当前分配先看现状。拿到一台机器最直接的办法是用lspci查看设备的详细BAR分配lspci -s NN:NN.N -vvv把NN:NN.N替换成目标设备的总线号、设备号、功能号。输出里会看到类似这样的内容Region 0: Memory at f0000000 (64-bit, prefetchable) [size16M] Region 1: Memory at f1000000 (64-bit, prefetchable) [size256K]这里的意思是BAR0被分配在0xf0000000空间大小16MB它是64位、可预取的。BAR1在0xf1000000大小256KB。这些地址就是CPU物理地址空间里的映射起点。再从内核的视角确认一下cat /proc/iomem | grep -i pci这条命令会列出内核记录的物理地址占用情况包括哪些区域被PCI设备占用。如果发现某个设备的BAR地址和lspci显示不一致通常是固件、内核分配策略之间有信息差这时候要警惕。还可以直接读内核sysfs暴露出的每个PCI资源cat /sys/bus/pci/devices/NN:NN.N/resource文件里每行代表一个BAR的起始地址、结束地址、属性标志。它是驱动开发时最常被忽略的调试入口却往往能最快发现“地址被谁占了”。4.2 用setpci现场验证BAR探测理论说再多不如亲手做一遍。系统里通常有setpci命令可以读写PCI配置空间。我们可以安全地复制一遍枚举算法。先保存当前值setpci -s NN:NN.N BAR0.l假如输出是f0000000记下它。然后执行setpci -s NN:NN.N BAR0.lffffffff setpci -s NN:NN.N BAR0.l这次读回的应该是类似fff00000的值它表示设备只响应高位地址低20位全是0。把低4位类型位去掉后取反加一就得到空间大小1MB。验证完恢复原值setpci -s NN:NN.N BAR0.lf0000000这里必须强调这条命令会让设备暂时失去原有地址映射如果正在使用的网卡、磁盘控制器做这种操作系统极可能当场卡死。务必在测试机、虚拟机里做并且恢复原值前不要访问设备。我一般会在系统刚启动、设备空闲时做这个实验。4.3 写一个最小驱动验证MMIO读写命令行只能看到“哪里映射了”要真正体验“映射后怎么访问设备”还是得写点代码。下面这个最小内核模块读取并写回BAR0的一个偏移用来验证整条MMIO通路#include linux/pci.h #include linux/io.h static void __iomem *bar0_base; static struct pci_dev *pdev; static int __init mmio_demo_init(void) { resource_size_t start, len; u32 orig, check; /* 用目标设备的Vendor ID和Device ID找到它 */ pdev pci_get_device(0x1234, 0x5678, NULL); if (!pdev) return -ENODEV; pci_enable_device(pdev); start pci_resource_start(pdev, 0); len pci_resource_len(pdev, 0); bar0_base ioremap(start, len); if (!bar0_base) { pci_disable_device(pdev); return -ENOMEM; } /* 读写BAR0偏移0处验证通路 */ orig readl(bar0_base); writel(0xdeadbeef, bar0_base); check readl(bar0_base); pr_info(MMIO demo: orig0x%08x check0x%08x\n, orig, check); iounmap(bar0_base); pci_disable_device(pdev); return 0; }这段代码看起来简单但它背后用到了几件关键机制pci_resource_start/pci_resource_len从设备结构体里读出固件或内核分配的BAR地址和大小。ioremap把物理地址映射成内核虚拟地址同时设置好“设备内存”的页表属性禁用缓存。readl/writel完成带内存屏障的32位访问确保读写顺序不被CPU乱序执行打乱。编译加载后看内核日志dmesg | tail如果能看到orig和check都是0xdeadbeef说明CPU已经成功通过PCIe链路读到了设备寄存器里的值。整条MMIO通路是通的。4.4 从设备树看嵌入式平台的映射差异前面说的都是x86这类“CPU域和PCI域几乎一致”的平台。嵌入式系统完全是另一种玩法。很多SoC的PCIe控制器需要靠DT设备树里的ranges属性告诉内核PCI侧的地址和CPU侧地址到底怎么对应。典型的PCIe控制器节点里会有这样一段ranges 0x01000000 0x0 0x00000000 0x0 0xef000000 0x0 0x01000000, 0x02000000 0x0 0xc0000000 0x0 0xc0000000 0x0 0x20000000;这行在说什么ranges每个条目六个数字格式是“子地址、父地址、映射长度”。第一个数的高字节表示窗口类型0x01000000是IO窗口0x02000000是32位MMIO窗口。后面按顺序是PCI侧起始地址、CPU侧起始地址、映射长度。第二条的意思就是PCI侧的0xc0000000开头、长度0x20000000512MB区间映射到了CPU物理地址的0xc0000000位置。在这个平台上PCI侧地址和CPU侧地址恰好一样。但如果SoC设计成PCI侧地址需要偏移ranges里的父地址就会和子地址不同。这也是嵌入式BSP工程师最容易踩坑的地方明明设备BAR显示正常的PCI地址驱动一访问就崩查了半天才发现是设备树的ranges没有配好CPU侧根本找不到对应的物理地址。5. 常见问题与排查技巧实录5.1 设备“看得见”但一访问就全F或机器重启这类问题我遇到的频率最高。lspci能看到设备说明配置空间访问是通的。但一操作某个BAR对应的寄存器读回全是0xFFFFFFFF或者直接触发机器检查异常。优先检查三件事设备的BAR是否真的被分配了地址。看lspci -vvv的Region行如果显示Memory at noop说明资源分配阶段出了问题。BAR地址是否落在RC窗口内。特别是64位BAR检查是否高于4GB而固件没开Above 4G解码。设备是否被正确复位。设备上电后如果没进入正常工作状态即使地址分配正确它也不会响应MMIO请求而是返回全F。一个比较隐蔽的原因是访问偏移越界。BAR空间大小是有限的你向BAR0偏移访问了一个超过size范围的位置RC和行为就可能完全偏离设备预期。驱动里的寄存器偏移表一定要和datasheet反复核对。5.2 PCI空洞不够大BAR无处安放老平台、32位固件环境下经常出现多张需要大MMIO空间的设备无法同时工作的情况。一个显存2GB的显卡在32位地址空间里根本找不到连续区域来放置它的BAR于是枚举失败或地址冲突。解决办法很直接但需要硬件和固件配合如果是64位系统进固件打开Above 4G Decoding让64位BAR分配到4GB以上的窗口。确认卡上所有BAR都是64位可预取的如果某张卡只支持32位BAR那是硬件限制再大的固件窗口也帮不上忙。减少不必要的设备或者调整插槽位置影响PCIe桥的窗口分配顺序。这个问题的本质是“设备地址空间需求”和“系统可用地址窗口”之间的供需失衡。排查时先看/proc/iomem里高位窗口有没有被保留再看每张卡的BAR类型别一上来就怀疑驱动。5.3 64位BAR在旧平台上的坑现代设备很多采用64位BAR但旧固件里的PCI枚举逻辑可能不完整常见表现是设备BAR读出来的地址只有低32位有意义高32位全是0或者高32位是个随机遗留值。这种情况下如果系统驱动直接沿用这个“半成品”地址去访问超过4GB的部分RC又没开相应窗口结果自然是访问失败。更麻烦的是有些固件会在枚举时把64位BAR错误当成两个独立的32位BAR分别分配了两段地址导致设备实际响应范围和驱动预期的完全错开。排查这类问题要看三个地方lspci -vvv里BAR是否显示64-bit/proc/iomem里设备资源范围是否完整固件/内核日志里有没有关于BAR重新分配的提示。如果固件处理得不好Linux内核通常会在启动后用自己的一套PCI资源分配逻辑重新分配BAR覆盖固件留下的错误值。这就是为什么同一张卡在某些机器上工作正常、某些机器上一访问就出问题的原因之一。5.4 命中和没命中排障速查表综合这些年的调试场景我整理了一张快速定位表遇到MMIO相关问题会先按这个顺序过一遍。现象优先检查项常用手段读BAR全F设备是否未复位、BAR是否分配过lspci -vvvsetpci读写恢复驱动加载成功但读写崩BAR地址与RC窗口是否匹配比对/proc/iomem与lspci系统启动时资源冲突多个BAR地址重叠查内核日志的BAR报错行访问4GB以上地址失败Above 4G Decoding未开进固件打开相关选项只有32位系统可用设备BAR类型过大换用支持大BAR的硬件或64位系统设备树平台不能识别ranges未配置或配置错用DT工具解析节点实际地址翻译这张表不能替代datasheet但能帮你把大部分“看起来像驱动问题”的MMIO坑排除掉。5.5 几个值得长期保持的排障习惯最后分享几个我自己一直在用的操作习惯。第一拿到一块新板卡先别急着写驱动。用lspci -vvv把所有BAR的类型、大小、当前地址抄下来再和/proc/iomem比对一遍。确认BAR在系统里的真实落点比看十遍寄存器手册都管用。第二凡是涉及写BAR的操作一定先备份原值。哪怕只是临时测试也要准备恢复命令。很多设备对BAR写入时机非常敏感一旦在设备忙碌时改掉地址轻则丢配置重则整条总线上的设备一起失效。第三访问前先确认设备已经pci_enable_device。内核里这个调用不只是“打开设备”它还会确保设备的资源管理和电源状态正确。漏掉这一步后续MMIO访问失败几乎可以预定。第四也是最重要的一条经验MMIO地址错了和驱动逻辑错了表现出来的症状几乎一样。都是读写返回异常、系统崩溃、设备无响应。但排查方法完全不同。所以永远先确认“地址通路是否正常”再去怀疑寄存器逻辑。地址通了寄存器操作才谈得上对错。我自己的体会是PCI内存映射这套机制说到底是硬件、固件、内核三方配合的一场“地址分配仪式”。每个环节都默不作声却又环环相扣。弄懂它很多看似诡异的硬件故障就只剩下一层窗户纸了。