pcie卡信息四元组信息的获取方式

[c32520]

问题描述

系统管理->系统信息->pcie卡界面，4元组信息，vendorid和deviceid是pmu读出来的，subvendorid和subdeviceid取的卡sr配置文件的

环境信息

• 软件版本：[如 OpenUBMC2606]

重现步骤

必现

期望结果

代码路径：\pcie_device\src\lualib\biz_topo\class\pcie_addr_info.lua

代码：function c_pcie_addr_info:update_vid_did(vid, did)

       print('\[pcie_addr_info\] update_vid_did enter, vid=', vid, ', did=', did)

       self:set_prop('VendorID', vid)

       self:set_prop('DeviceID', did)

    end

想了解下当前代码实现，

①bios上报设备bdf，根据bdf从pmu拿到四元组信息，vendor id和device id是从pmu拿，deviceid和subdeviceid从网卡sr配置文件拿，是有什么背景吗？

②可以4元组信息都从pmu拿吗？

[ubmc_assistant (openUBMC_Assistant)]

答案内容由AI生成，仅供参考：
根据您提供的上下文信息，关于PCIe卡四元组信息（VendorID、DeviceID、SubVendorID、SubDeviceID）的获取方式，可以总结如下：

获取机制概述

PCIe设备四元组信息的获取遵循 “零配置纳管” 的设计逻辑，其核心流程为：

1. BDF上报：BIOS启动阶段主动上报每个PCIe槽位的 BDF（Bus/Device/Function） 信息。
2. 四元组查询：BMC通过PMU（或IMU）根据BDF信息查询对应的设备四元组（VID/DID/SubVID/SubDID）。
3. CSR加载：使用四元组拼接成AuxID和ID，进而构成sr文件名（格式为Bom_{DeviceID}_{VendorID}_{SubDeviceID}_{SubVendorID}.sr），触发框架自发现加载PCIe设备CSR。

当前数据来源分析

从您描述的现象（VendorID和DeviceID是PMU读出来的，SubVendorID和SubDeviceID是取得CSR配置信息）来看，这反映了系统设计中数据获取与配置回退的机制：

• PMU（IMU）查询能力：上下文明确提及bmc.kepler.Systems.Pmu接口中存在GetPcieVidDid（获取VID/DID）和GetPcieSubVidDid（获取SubVID/SubDID）两个方法，理论上PMU具备提供完整四元组的能力。这通过命令示例busctl --user call bmc.kepler.compute /bmc/kepler/Systems/1/Pmu bmc.kepler.Systems.Pmu GetPcieVidDid a{ss}ybyyyy 0 1 true 0 1 0 0可验证。
• CSR配置的补充作用：openUBMC系统的设计严格要求所有PCIe设备必须通过SR/CSR文件明确定义才能被识别和管理（见“未适配的PCIe卡无法在Web上显示在位问题分析”文档）。因此，在Web界面显示时，系统可能优先展示通过CSR文件配置的属性（如SubVendorID、SubDeviceID），而将PMU实时读取的VID/DID用于动态识别和设备匹配。

针对“四元组信息都从PMU拿”的期望

基于现有代码逻辑，完全可以从PMU获取全部四元组信息，理由如下：

1. PMU接口支持：GetPcieSubVidDid方法明确用于“检索PCIe设备的子供应商ID和子设备ID”，结合GetPcieVidDid，可完整获取四个字段。
2. 加载流程依赖PMU：PCIe设备动态加载流程中，BMC通过BDF向PMU查询四元组，若PMU查询成功，则四元组是设备识别和CSR匹配的基础数据（见“PCIe设备加载”文档中步骤5：查看是否能通过IMU获取四元组）。
3. CSR文件的局限性：CSR文件主要存储设备特性配置（如固件版本、管理协议等），而非设备身份信息。若未适配的PCIe卡缺少对应SR文件，即使PMU成功返回四元组，Web界面也可能因缺少配置而无法显示在位——这解释了为何当前界面显示可能出现“一部分来自PMU、一部分来自CSR”的混合状态。

改进建议

若需将四元组信息全部统一从PMU获取，建议：

1. 确认PMU侧完整性：检查GetPcieVidDid和GetPcieSubVidDid返回的完整性和准确性，尤其是SubVID/SubDID字段（某些设备可能返回0xffff或空值，如DPU卡）。
2. 调整Web展示逻辑：在获取到PMU完整四元组后，优先使用实时数据填充Web界面；同时对CSR配置中的SubVendorID/SubDeviceID进行一致性校验，避免两者冲突。
3. 补充异常处理：若PMU无法返回SubVID/SubDID（如IMU通信失败），可回退到CSR配置信息，并在日志中记录差异（类似app.log中Get id from PMU关键字的监控）。

综上所述，当前代码已具备从PMU获取四元组信息的完整接口，调整的关键在于明确Web展示层的数据优先级（PMU实时数据 > CSR静态配置），并处理好PMU读取失败时的回退逻辑与告警记录。

[aliens_to_mars (HuangDing)]

从卡适配的角度上来讲，单张卡的vid did subvid subdid应该都是一致的，所以从sr里来和从带内读取应该一致，sr文件就是通过四元组去匹配的。

为了减少数据同步次数，PCIeCard对象加载上来的时候是在sr中配好四元组的。

会有部分卡多个subvid/did共用一个vid/did，因此读取的时候优先会保证vid/did能读取，就可以通过这个加载一个系列的卡默认的sr。

如果需要自行适配，是可以所有都来自pmu的，但是这种情况需要考虑部分卡是否有加载问题。