1. 从装不上和透传报错说起裸金属适配到底卡在哪搞过裸金属交付的人大概都有这种体验服务器上架、系统装完满心欢喜准备跑业务结果网卡驱动死活加载不上好不容易驱动起来了做网卡直通给虚拟机用又给你甩一个透传失败。这类问题最折磨人的地方在于它不像应用层报错那样有清晰的堆栈很多时候就是一句probe failed或者干脆静默——设备在lspci里看得见ip link里就是不出来。我这些年经手的裸金属适配场景粗略分下来卡点基本集中在三类芯片上网卡芯片、存储控制器芯片、以及各类加速/管理类芯片。这三类的适配逻辑差异很大但踩的坑有共性——都绕不开驱动加载链路和设备透传链路这两条主线。所谓裸金属适配说白了就是让操作系统在没有任何虚拟化层兜底的情况下直接把这颗芯片认出来、驱动起来、并且能安全地交给上层无论是宿主机还是虚拟机使用。这里要先厘清一个概念很多人把驱动装不上和透传报错当成两个独立问题其实它们经常是同一条链路上的前后两环。驱动没装好透传必然失败但驱动装好了透传照样可能失败因为透传还额外牵扯 IOMMU 分组、设备隔离、以及中断重映射这些机制。我在实际排查中总结出一条经验先确认驱动层是否真正 probe 成功再去看透传层顺序不能反。反过来查你会在透传报错里绕很久最后发现根因是驱动根本没起来。这篇内容我想把三类芯片的适配经验系统梳理一遍重点讲清楚每一步为什么这么做以及那些文档里不会写、只有真机上手才会遇到的坑。适合正在做裸金属交付、信创适配、或者自研硬件平台的操作系统工程师参考。哪怕你只是偶尔要装个驱动、配个直通这里面的排查思路也能直接抄。2. 网卡芯片驱动加载与直通透传的双重考验2.1 为什么网卡适配最容易翻车网卡是裸金属场景里适配优先级最高的设备也是最容易出问题的。原因有三第一网卡型号极其繁杂同一家厂商不同批次可能用不同芯片第二网卡驱动往往涉及固件firmware加载固件缺失是高频故障点第三网卡直通给虚拟机时对 IOMMU 分组的要求最苛刻。我遇到过最典型的一个案例某国产网卡在lspci -nn里能看到设备dmesg里却只有一行probe with driver xxx failed with error -2。error -2 是ENOENT翻译过来就是找不到东西——十有八九是固件文件没放对位置。很多人第一反应是驱动没编译进去其实驱动模块lsmod看是在的真正缺的是/lib/firmware/下那个.bin文件。提示遇到probe failed且错误码是负数时先查dmesg | grep -i firmware固件缺失比驱动缺失更常见。2.2 驱动加载链路的完整排查顺序我习惯按下面这个顺序排查基本能覆盖九成以上的网卡驱动问题确认设备是否被总线识别lspci -nn | grep -i ethernet如果这里都看不到那是硬件或 BIOS 层面的问题跟驱动无关。确认内核是否匹配到驱动lspci -k会显示 Kernel driver in use 和 Kernel modules 两行。如果 driver in use 是空的说明没匹配上。确认驱动模块是否存在modinfo 驱动名如果报 Module not found说明驱动没编进内核也没作为模块安装。手动加载看报错modprobe 驱动名然后立刻dmesg | tail -30这一步能拿到最原始的失败原因。检查固件dmesg | grep -i firmware缺固件就去厂商官网或内核 firmware 仓库找对应文件。这套顺序的价值在于逐层缩小范围。我见过有人一上来就重装系统结果问题只是固件没放白白折腾半天。也见过有人反复modprobe却从不看dmesg等于闭着眼睛修车。2.3 网卡直通透传IOMMU 分组才是真正的拦路虎驱动起来之后做网卡直通PCI Passthrough给虚拟机报错往往变成Failed to assign device: Device is not isolatable或者group not viable。这类报错的根因是IOMMU 分组——同一分组内的设备必须一起直通不能只挑一个。为什么会有分组因为 IOMMU 是以组为单位做地址翻译和隔离的硬件上共享同一条上游桥的设备会被划进同一组。如果网卡和某个关键设备比如系统盘控制器分在同一组你就没法单独把网卡直通出去否则会连带把系统盘也隔离掉。排查方法很直接# 查看 IOMMU 分组情况 for d in /sys/kernel/iommu_groups/*/devices/*; do n${d#*/iommu_groups/*}; n${n%%/*} printf IOMMU Group %s $n lspci -nns ${d##*/} done如果发现网卡和别的设备挤在一组有几个应对思路一是换 PCIe 插槽物理位置变了分组往往也变二是在 BIOS 里开启 ACSAccess Control Services它能强制拆分分组三是接受现实整组直通。ACS 这个选项不是所有主板都有我实测下来服务器主板支持率比消费级主板高得多。注意开启 ACS 有时会带来轻微性能开销因为它增加了 PCIe 层面的隔离检查。生产环境要权衡测试环境可以放心开。2.4 一个容易被忽略的细节驱动版本与内核版本的匹配网卡驱动和内核版本不匹配是驱动装上了但性能异常的隐形杀手。表现通常是网卡能起来、能通但吞吐量上不去或者偶发丢包。这种情况dmesg里往往没有明显报错特别难查。我的做法是优先用内核自带的 in-tree 驱动除非厂商明确要求用 out-of-tree 版本。in-tree 驱动跟着内核走兼容性最有保障。如果必须用厂商驱动一定要确认它支持的 kernel 版本范围并且用dkms管理避免内核升级后驱动失效。# 用 dkms 管理厂商驱动内核升级后自动重编 dkms add -m 驱动名 -v 版本 dkms build -m 驱动名 -v 版本 dkms install -m 驱动名 -v 版本dkms 的好处是内核一升级它会自动触发重编译省得你每次升级完发现网卡没了再手忙脚乱。这个习惯我从很早以前就养成了强烈建议所有用厂商驱动的场景都配上。3. 存储控制器芯片从识别到透传的完整链路3.1 存储控制器适配的特殊性存储控制器HBA、RAID 卡的适配和网卡不太一样。网卡挂了顶多没网存储控制器挂了可能直接导致系统起不来或者数据盘全部不可见。所以这类芯片的适配稳定性优先级高于一切。存储控制器常见的适配问题有两类一是驱动加载顺序问题二是直通后宿主机与虚拟机争抢设备。第一类里最典型的是 RAID 卡——很多 RAID 卡需要先加载管理驱动再加载块设备驱动顺序错了就认不到盘。第二类则是直通场景下的经典矛盾你把 HBA 直通给虚拟机宿主机就看不到这块卡上的盘了如果宿主机恰好需要这块盘做点什么就会出问题。3.2 驱动加载顺序与依赖处理Linux 的模块加载顺序由modules.dep和modprobe的依赖关系决定但有些厂商驱动的依赖关系没写清楚导致加载顺序不对。排查这类问题我一般这样做# 查看模块依赖关系 modprobe --show-depends 驱动名 # 查看当前已加载模块的顺序 lsmod | head -50 # 强制按指定顺序加载 modprobe 底层驱动 modprobe 上层驱动如果发现顺序确实有问题可以在/etc/modprobe.d/下写一个配置文件用softdep声明依赖# /etc/modprobe.d/storage.conf softdep upper_driver pre: lower_driversoftdep的意思是加载 upper_driver 之前先加载 lower_driver。这个机制比硬编码顺序灵活也不会因为手动 modprobe 顺序不对而出错。我踩过的坑是早期不知道 softdep每次重启都要手动按顺序加载后来写进配置才彻底解决。3.3 存储控制器直通数据安全的第一道防线存储控制器直通给虚拟机最大的风险是宿主机和虚拟机同时访问同一块盘轻则文件系统损坏重则数据丢失。所以直通之前必须确认宿主机上没有挂载这块卡上的任何分区。# 确认设备没有被挂载 lsblk mount | grep 设备名 # 确认没有进程占用 lsof | grep 设备名确认干净之后还要在虚拟机配置里正确声明设备。以常见的虚拟化平台为例直通配置需要指定 PCI 地址并且要确保 IOMMU 分组允许。存储控制器的分组问题比网卡更敏感因为它经常和 PCIe 桥、其他控制器共享分组。我个人的经验是存储控制器直通能整组直通就整组直通不要试图拆分。拆分带来的隔离风险远大于省下那点资源的收益。如果分组实在不理想宁可换插槽或者换主板也别硬拆。3.4 直通后的性能验证不能省存储控制器直通完很多人看到虚拟机里盘出来了就以为完事了。其实性能验证这一步不能省因为直通配置不当会导致性能大幅下降而且这种下降往往不报错只是慢。验证方法很简单在虚拟机里跑一次顺序读写和随机读写# 顺序写测试 dd if/dev/zero of/mnt/testfile bs1M count4096 oflagdirect # 随机读测试需要 fio fio --namerandread --ioenginelibaio --iodepth32 \ --rwrandread --bs4k --direct1 --size1G \ --filename/mnt/testfile --runtime60把结果和宿主机直接访问时的数据对比如果差距超过 20%就要回头查直通配置。常见原因是中断重映射没开、或者设备没真正走直通而是走了模拟。这个对比习惯帮我抓到过好几次看起来正常实则降级的配置问题。4. 加速与管理类芯片小众但坑深的适配场景4.1 这类芯片为什么难搞加速类芯片各类计算加速、加解密加速和管理类芯片BMC 相关、带外管理的适配难点在于资料少、社区小、厂商支持参差。网卡驱动出问题网上搜一搜一大把案例加速芯片出问题可能全网就你一个人在踩。这类芯片的适配我总结出三个关键点固件版本要严格对齐、驱动要认准厂商指定版本、透传前要确认芯片是否支持虚拟化。第三点尤其重要——不是所有加速芯片都支持直通有些芯片硬件上就没做 SR-IOV 或者隔离能力你硬配直通只会得到一堆莫名其妙的报错。4.2 固件与驱动的版本对齐加速类芯片对固件和驱动的版本匹配要求比网卡严格得多。网卡固件旧一点可能只是少几个特性加速芯片固件和驱动不匹配可能直接导致功能不可用甚至设备挂死。我的做法是拿到芯片第一件事记录当前固件版本然后去厂商文档里找推荐的驱动版本矩阵。这个矩阵通常是一张表明确写了哪个固件版本配哪个驱动版本。不要凭感觉升级也不要觉得越新越好。# 查看设备固件版本不同厂商命令不同以下是通用思路 厂商工具 --version 厂商工具 --query-firmware # 查看驱动版本 modinfo 驱动名 | grep version如果厂商没提供版本矩阵那就保守一点用出厂固件配出厂驱动先跑通再说。我吃过一次亏手贱把固件升到最新结果驱动不认回滚固件又特别麻烦折腾了一整天才恢复。4.3 透传前的虚拟化能力确认加速芯片直通前一定要确认它支持哪种虚拟化方式。常见的有三种全设备直通PCI Passthrough、SR-IOV、以及厂商自定义的虚拟化方案。三者的配置方式和限制完全不同。虚拟化方式隔离粒度配置复杂度适用场景全设备直通整卡低单虚拟机独占整卡SR-IOV虚拟功能VF中多虚拟机共享物理卡厂商自定义视方案而定高特定厂商生态确认方法查芯片手册里的 SR-IOV 支持情况或者直接看lspci -vvv里有没有 SR-IOV 能力位。# 查看设备是否支持 SR-IOV lspci -vvv -s PCI地址 | grep -i Single Root I/O如果没有 SR-IOV 能力位那就只能走全设备直通一台虚拟机独占整卡。这个限制要在规划阶段就搞清楚否则等到部署时才发现架构就得推倒重来。4.4 管理类芯片的带外适配管理类芯片比如 BMC的适配有个特殊性它往往在操作系统启动之前就已经在工作了操作系统里的驱动更多是提供带内管理接口。这类芯片的适配问题通常表现为带内工具读不到信息或者读到的信息和带外不一致。排查这类问题关键是分清带内和带外两条路径。带外走的是管理网口和 IPMI/Redfish 协议带内走的是操作系统里的驱动和字符设备。两条路径独立一条通不代表另一条通。# 带内查看 BMC 信息以 ipmitool 为例 ipmitool mc info # 如果带内读不到检查驱动和设备节点 ls /dev/ipmi* dmesg | grep -i ipmi我遇到过一次带内工具完全读不到 BMC 的情况最后发现是内核配置里没开 IPMI 相关选项。这种问题在定制内核的场景下特别常见标准发行版一般不会缺。5. 把适配经验沉淀成可复用的排查方法论5.1 建立设备-驱动-固件三件套台账适配做多了最怕的是重复踩同一个坑。我的做法是给每个适配过的芯片建一条台账记录三样东西设备 IDvendor:device、驱动名称与版本、固件版本。下次遇到同型号芯片直接查台账省去大量试错。# 快速提取设备 ID lspci -nn | grep -i 设备类型 # 输出示例03:00.0 Ethernet controller [0200]: Vendor Inc. Device [1234:5678] # 其中 1234:5678 就是 vendor:device台账不用多复杂一个 Markdown 表格就够。关键是坚持记尤其是那些折腾了很久才搞定的案例一定要把最终生效的配置记下来。我现在的台账里躺着几十条记录好几次新项目遇到老芯片直接翻台账五分钟解决。5.2 透传失败的通用排查树透传报错五花八门但排查路径可以收敛成一棵树。我把它整理成下面这个顺序基本能覆盖绝大多数情况驱动层设备是否 probe 成功lspci -k看 driver in use。IOMMU 层IOMMU 是否开启dmesg | grep -i iommu看有没有 DMAR 或 AMD-Vi 相关报错。分组层设备所在 IOMMU 分组是否可隔离用前面那段脚本查。配置层虚拟化平台的直通配置是否正确PCI 地址有没有写错权限层当前用户/服务是否有权限操作该设备这五层从下往上查每层确认通过再进下一层。我见过太多人跳过前三层直接改配置结果配置改了一堆根因还在驱动层。5.3 那些文档不会写的实操心得最后分享几条纯经验性的东西都是踩坑踩出来的第一重启大法在驱动适配里真的有用但要会用。有些驱动加载失败是因为前一次加载残留了状态rmmod再modprobe不一定干净重启反而最彻底。但重启之前一定要把dmesg存下来否则重启后现场就没了。第二BIOS 设置是很多问题的隐藏开关。IOMMU、ACS、SR-IOV、Above 4G Decoding 这些选项默认值往往不是最优的。适配前先把 BIOS 里跟虚拟化、PCIe 相关的选项过一遍能省掉后面很多麻烦。第三善用dmesg -w实时观察。很多驱动问题是瞬时的等你反应过来已经过去了。开一个终端挂着dmesg -w另一个终端做操作报错第一时间就能看到。第四厂商支持渠道要用起来。加速类和管理类芯片遇到搞不定的问题别硬扛直接找厂商 FAE。他们有内部文档和已知问题列表往往一句话就能点破你查了一天的东西。第五适配环境要留快照。不管是虚拟机快照还是物理机备份适配前留一个干净状态。驱动装崩了、固件刷坏了能快速回滚。这个习惯救过我至少三次。5.4 关于 AI Skill 的一点实际体会标题里提到把适配经验收进 AI Skill这个思路我觉得挺实在。适配这类工作最值钱的就是遇到 X 报错先查 Y再查 Z这种经验性判断而这些恰恰是通用文档里最缺的。把排查树、台账、常见报错对照表整理成一个结构化的知识库让 AI 能按图索骥地引导排查比让人去翻几百页手册高效得多。我自己整理排查树的时候有个原则每个判断节点都要有明确的验证命令和预期输出。比如确认驱动是否 probe 成功这个节点验证命令是lspci -k预期输出是 Kernel driver in use 那一行非空。这样无论是人还是 AI执行起来都不会有歧义。经验这东西只有被拆解成可执行、可验证的步骤才真正具备复用价值。三类芯片的适配说到底就是驱动链路和透传链路两条主线加上固件、IOMMU、分组这几个关键变量。把变量控制住把排查顺序固定下来再刁钻的芯片也能一步步啃下来。