Bluefield DPU通过rshim管理：从安装到故障排查全指南

1. 初识rshim：你的Bluefield DPU“软”管理口

如果你刚拿到一块NVIDIA Bluefield DPU，准备大展拳脚，可能会发现除了传统的SSH和带外管理（OOB）之外，还有一种更“底层”、更直接的管理方式。没错，我说的就是rshim。你可以把它想象成DPU的一个“虚拟串口”或者“软件BMC接口”，它直接通过PCIe通道，在主机（Host）和DPU的Arm核心之间建立了一条专属的管理通道。

我刚开始接触Bluefield DPU时，也习惯性地去找物理串口或者拼命配置网络，后来才发现，用好rshim，很多操作会变得异常简单。比如，当DPU的OS还没启动、网络没配好，甚至系统“挂了”的时候，你依然可以通过主机上的rshim服务，直接访问DPU的控制台（console），进行系统安装、故障恢复、BMC管理，或者查看底层启动日志。这就像是给服务器主板接上了物理串口线，只不过这根“线”是虚拟的、通过PCIe走的。

那么，rshim具体能干什么呢？我总结了几点最常用的场景：

1. 控制台访问：这是最核心的功能。通过/dev/rshim0/console，你可以像使用物理串口一样，登录到DPU的UEFI界面或Arm OS的登录提示符。这在系统安装初期或网络故障时是救命稻草。
2. 系统安装与升级：使用bfb-install工具，你可以通过rshim通道，将BFB（BlueField Bootstream）镜像直接“推”到DPU上进行系统安装或固件升级，整个过程都在主机侧完成，无需依赖DPU侧的网络。
3. 状态监控与信息读取：通过读取/dev/rshim0/misc文件，你可以获取DPU的设备型号、PCIe地址、启动模式等底层信息，这对于故障诊断和硬件识别非常有用。
4. 执行底层控制：比如，你可以通过向特定的rshim文件写入命令，来触发DPU的软复位、修改启动参数，甚至管理BMC。这提供了比SSH更底层的控制能力。

简单来说，rshim是连接主机与DPU Arm核心的一座“特权桥梁”。它不依赖于DPU上运行的操作系统网络栈，只要DPU硬件上电、PCIe链路正常，并且主机上安装了正确的驱动和服务，这座桥就是通的。接下来，我们就从零开始，搭建这座桥。

2. 从零部署：在主机上安装并启动rshim服务

很多朋友第一次遇到的问题是：在主机上根本找不到/dev/rshim0这个设备节点。别慌，这太正常了，因为rshim并不是一个标准的Linux内核模块，它需要单独安装。下面我就带你走一遍完整的安装和验证流程，这里面的坑我都踩过，你跟着做就行。

2.1 环境检查与依赖安装

在动手安装之前，我们先确认几件事。首先，确保你的Bluefield DPU已经正确插入服务器的PCIe插槽，并且被主机系统识别。运行lspci命令，你应该能看到类似下面的输出，关键是要找到带有“SoC Management Interface”字样的设备行，这就是rshim对应的PCIe功能。

lspci | grep -i mellanox # 或者更精确地查找rshim lspci | grep -i "SoC Management"

一个典型的输出示例如下：

27:00.0 Ethernet controller: Mellanox Technologies MT42822 BlueField-2 integrated ConnectX-6 Dx network controller 27:00.1 Ethernet controller: Mellanox Technologies MT42822 BlueField-2 integrated ConnectX-6 Dx network controller 27:00.2 Non-Volatile memory controller: Mellanox Technologies NVMe SNAP Controller 27:00.3 DMA controller: Mellanox Technologies MT42822 BlueField-2 SoC Management Interface # 就是这一行！

看到最后一行，恭喜你，硬件识别没问题。接下来，我们需要根据你的主机操作系统，来安装rshim软件包。rshim通常包含在doca-runtime这个包里面，这是NVIDIA DOCA开发套件的一部分。但如果你只是需要管理功能，不需要完整的DOCA SDK，那么只安装doca-runtime就足够了。

2.2 分步安装rshim（以CentOS/RHEL为例）

假设你的主机是CentOS 7.x或8.x（包括Rocky Linux、AlmaLinux等RHEL兼容系统），安装过程非常直接。你需要先从NVIDIA官方获取DOCA主机仓库的RPM包。你可以访问NVIDIA DOCA下载页面，找到对应你操作系统版本的doca-host-repo包。

拿到RPM包后，按顺序执行以下命令：

# 1. 安装DOCA主机仓库 sudo rpm -Uvh doca-host-repo-rhel<版本号>.x86_64.rpm # 2. 更新yum或dnf缓存（CentOS 7用yum，8/9用dnf） # 对于CentOS 7/RHEL 7： sudo yum makecache # 对于CentOS 8/RHEL 8/Rocky 8： sudo dnf makecache # 3. 安装doca-runtime包，它会自动包含rshim # 对于CentOS 7/RHEL 7： sudo yum install -y doca-runtime # 对于CentOS 8/RHEL 8/Rocky 8： sudo dnf install -y doca-runtime

对于Ubuntu或Debian系统，过程类似，只是包管理工具换成了dpkg和apt：

# 1. 安装DOCA主机仓库DEB包 sudo dpkg -i doca-host-repo-ubuntu<版本号>_amd64.deb # 2. 更新软件源 sudo apt-get update # 3. 安装doca-runtime sudo apt install -y doca-runtime

安装完成后，先别急着高兴。这时候你执行ls /dev/rshim*很可能还是什么都看不到。因为安装的只是软件包，对应的系统服务（rshim.service）还没有启动。这是新手最容易困惑的一点：rshim是以一个后台服务（daemon）的形式运行的，它会动态创建设备节点。

2.3 启动服务与验证

安装完包，下一步就是启动服务。我们来检查并启动它：

# 检查rshim服务状态，大概率是未运行或未激活 sudo systemctl status rshim # 启动rshim服务 sudo systemctl start rshim # 或者使用restart，如果服务存在但状态不对 sudo systemctl restart rshim # 再次检查状态，应该看到 active (running) sudo systemctl status rshim

一个健康的systemctl status rshim输出应该包含“active (running)”状态，并且下面会打印出类似“Probing pcie-0000:04:00.2”和“rshim0 attached”的日志信息。这表明服务已经成功找到了你的Bluefield DPU并挂载了rshim后端。

现在，最激动人心的时刻来了，再次列出/dev下的设备：

ls -la /dev/rshim*

你应该能看到/dev/rshim0目录（如果有多块DPU，可能会有rshim1，rshim2等）。进入这个目录看看：

ls -la /dev/rshim0/

你会看到几个关键文件，比如console,misc,boot,reset等。每个文件都有其特定用途。现在，我们可以做一个最简单的验证，读取DPU的基本信息：

cat /dev/rshim0/misc | head -20

这个命令会输出一长串信息，重点关注以下几行：

• DEV_NAME: 显示rshim对应的PCIe设备地址（例如pcie-0000:04:00.2），这和你之前lspci看到的地址应该能对应上。
• DEV_INFO: 显示DPU的型号信息（例如BlueField-2(Rev 0)）。
• BOOT_MODE: 显示当前的启动模式（0表示rshim网络启动，1表示eMMC启动等）。

看到这些信息，就说明你的rshim通道已经成功建立，主机和DPU之间的“特权桥梁”正式通车了！

3. 实战应用：通过rshim进行日常管理与高级操作

安装和启动只是第一步，真正体现rshim价值的是在日常管理和故障处理中。下面我分享几个最实用的操作，这些都是我工作中经常用到的。

3.1 访问DPU控制台（Console）

这是rshim最经典的应用。通过它，你可以在DPU操作系统完全启动前就介入，比如修改UEFI启动顺序、进入救援模式，或者只是观察系统启动日志。使用screen或minicom这类终端工具可以连接：

sudo screen /dev/rshim0/console 115200

执行这条命令后，你就进入了DPU的串口终端。如果DPU的Arm OS正在运行，你会看到登录提示符（默认用户名/密码通常是ubuntu/ubuntu）。如果DPU还没启动，或者卡在UEFI界面，你也能在这里看到所有输出并与之交互。要退出screen会话，按Ctrl+A，然后按K，再按Y确认。

这里有个小技巧：有时候你可能需要同时监控控制台输出，又不想被一个终端会话独占。你可以使用cat或tail命令来只读地查看控制台输出，这在进行固件升级时观察进度非常有用：

# 只读方式查看控制台最新输出 tail -f /dev/rshim0/console # 或者清空当前缓冲区并持续查看 cat /dev/rshim0/console

3.2 使用bfb-install安装或升级DPU系统

这是rshim的“杀手级”应用。你可以直接从主机侧，为DPU安装全新的操作系统（BFB镜像），或者升级其固件，而完全不需要依赖DPU侧的任何网络服务。假设你已经下载好了BFB镜像文件（例如bfb-image.bfb），操作命令如下：

sudo bfb-install --bfb /path/to/bfb-image.bfb --rshim rshim0

这个命令会通过rshim通道，将BFB镜像流式推送到DPU，并触发其安装流程。整个过程务必保持耐心，不要中断！安装过程中，你可以通过上面提到的tail -f /dev/rshim0/console来实时观察安装日志。你会看到从PSC BL1、BL2、UEFI到Linux内核启动的完整过程。当最后出现“DPU is ready”的提示时，就表示安装成功了。

bfb-install还有很多有用的参数。例如，你可以通过--config指定一个配置文件（bf.cfg），来自定义安装过程，比如设置网络、密码、分区大小等。还可以用--keep-log参数保留完整的rshim日志用于调试。

# 使用自定义配置文件进行安装 sudo bfb-install --bfb bfb-image.bfb --config my_config.bf.cfg --rshim rshim0 --keep-log

3.3 执行DPU复位与电源控制

通过rshim，你可以对DPU进行“软复位”，这相当于按下了DPU Arm核心的复位按钮，而不会影响主机或其他PCIe功能。操作很简单：

# 向reset文件写入1，触发DPU复位 echo 1 | sudo tee /dev/rshim0/reset

执行后，你会通过控制台看到DPU立即重启。这个功能在DPU系统无响应、需要强制重启时非常有用。需要注意的是，这只会复位Arm核心，不会影响DPU上的NIC网络功能（如果运行在分离模式下）。

除了复位，你还可以通过rshim查询和修改一些底层参数。比如，查看和设置对端MAC地址（PEER_MAC），这个MAC地址是DPU侧tmfifo_net0接口的地址，是主机与DPU通信的虚拟网络接口的一部分。

# 首先，将显示级别设置为高级，以看到更多信息 echo "DISPLAY_LEVEL 1" | sudo tee /dev/rshim0/misc # 然后查看misc信息，找到PEER_MAC行 sudo cat /dev/rshim0/misc | grep PEER_MAC # 如果需要修改（通常不建议随意修改） # echo "PEER_MAC 00:1a:ca:ff:ff:02" | sudo tee /dev/rshim0/misc

4. 深入排查：常见rshim故障分析与解决

即使按照步骤操作，你也可能会遇到rshim工作不正常的情况。别担心，我把我遇到过的问题和解决方法都整理出来了。

4.1 服务启动失败或状态异常

问题现象：执行sudo systemctl status rshim后，服务状态不是active (running)，可能是failed、inactive或者不断重启。

排查思路：

1. 检查内核日志：首先，查看系统日志，寻找rshim相关的错误信息。journalctl是你的好朋友。

   sudo journalctl -u rshim -f # 实时跟踪rshim服务日志 sudo journalctl -u rshim -b # 查看本次启动以来的日志 sudo dmesg | grep -i rshim # 查看内核环缓冲区中与rshim相关的信息

   常见的错误包括：找不到PCIe设备、驱动模块加载失败、权限问题等。日志会给你明确的线索。

2. 确认PCIe设备存在且驱动加载：确保DPU的SoC管理接口在lspci中可见。如果看不到，可能是硬件问题、PCIe插槽问题，或者需要在主机BIOS中启用相关功能（如SR-IOV、PCIe访问控制等）。同时，检查相关的内核模块是否加载：

   lsmod | grep rshim lsmod | grep pcie

   如果rshim_pcie模块没有自动加载，可以尝试手动加载：sudo modprobe rshim_pcie。

3. 检查服务依赖：rshim服务可能有其他依赖。查看服务定义文件：

   systemctl cat rshim

   看看After=和Requires=字段指定的服务是否都已正常启动。

4.2 /dev/rshim0目录存在但无法访问

问题现象：/dev/rshim0目录存在，但对其中的文件（如console,misc）进行读写操作时失败，提示权限不足或输入/输出错误。

排查思路：

1. 检查文件权限和属主：ls -la /dev/rshim0/查看文件权限。通常这些文件应该对root用户可读写。如果属主或权限不对，可能是udev规则没有正确应用。可以尝试重启rshim服务或重新加载udev规则：

   sudo udevadm control --reload-rules && sudo udevadm trigger sudo systemctl restart rshim

2. 确认后端已正确附加：即使目录存在，也可能意味着rshim内核模块识别了设备，但用户空间服务未能成功“附加”（attach）。仔细查看systemctl status rshim的输出，确认是否有“rshim0 attached”或类似的成功信息。如果没有，并且有“another backend already attached”的错误，说明可能有其他进程（也许是之前残留的）占用了该设备。尝试彻底重启服务：

   sudo systemctl stop rshim sudo rmmod rshim_pcie # 卸载内核模块 sudo modprobe rshim_pcie # 重新加载 sudo systemctl start rshim

3. DPU状态问题：DPU本身可能处于一种异常状态，比如深度睡眠、复位中，或者SoC管理接口被禁用。尝试对主机服务器或DPU进行完全下电再上电（硬重启），这能解决很多底层硬件状态问题。

4.3 多DPU环境下的rshim管理

当一台主机上插了多块Bluefield DPU时，每块卡都会有一个独立的rshim设备，例如/dev/rshim0、/dev/rshim1等。管理时需要区分它们。

关键点：

• 识别对应关系：通过cat /dev/rshim0/misc和cat /dev/rshim1/misc查看DEV_NAME字段，里面的PCIe总线地址（如pcie-0000:03:00.2和pcie-0000:83:00.2）可以帮你确定每个rshim设备对应哪块物理卡（结合lspci输出）。
• 网络接口配置：每块DPU的tmfifo_net虚拟接口（如tmfifo_net0,tmfifo_net1）需要配置不同的IP和MAC地址，否则会在主机上产生冲突。你需要为每个接口配置独立的IP段，或者将它们桥接到同一个网桥。
• 服务启动顺序：如果多块DPU同时存在，确保rshim服务能正确识别并附加所有设备。有时可能需要调整服务脚本，或者确保所有DPU在服务启动前都已就绪。

一个常见的多DPU主机网络配置思路是创建一个网桥（例如br-tmfifo），然后将所有的tmfifo_netX接口都加入这个网桥，这样主机就可以通过同一个IP段与所有DPU通信。具体配置涉及编辑/etc/sysconfig/network-scripts/（RHEL系）或/etc/netplan/（Ubuntu）下的网络配置文件。

4.4 升级与兼容性问题

问题现象：在升级了主机内核、DPU固件或DOCA版本后，rshim服务无法正常工作。

排查思路：

1. 版本匹配：确保你安装的doca-runtime（包含rshim）版本与DPU的固件（BFB）版本大致兼容。虽然有一定向后兼容性，但跨度太大的版本有时会有问题。查看NVIDIA的官方发行说明，确认已知的兼容性问题。
2. 内核模块签名（针对Secure Boot开启的系统）：如果主机启用了Secure Boot，而rshim内核模块没有正确签名，会导致加载失败。你需要要么禁用Secure Boot（不推荐用于生产环境），要么使用由可信密钥签名的模块版本。检查dmesg日志中是否有关于模块签名验证失败的信息。
3. 回滚操作：如果升级后出现问题，最直接的方法是回退到之前已知正常的版本。记录下每个组件（内核、doca-runtime、DPU BFB）的版本，便于在出问题时快速回滚。

记住，日志是你的第一手资料。无论遇到什么问题，养成首先查看journalctl -u rshim和dmesg的习惯，大部分错误原因都会直接或间接地体现在日志里。