从灵衢资源管理到第三方芯片接入——IO Die的数据面与管理面适配

作者贺巍 方宜万强基于灵衢社区公开资源管理框架的第三方接入工程解读灵衢社区发布的《灵衢资源管理池化、隔离、调度、自愈》从UBFM、Entity、配置空间、资源空间、EID、UPI、中断、池化、远端内存和RAS等方面梳理了UB资源管理框架。对第三方芯片接入而言链路能够建立、数据能够传输只说明数据通路已经具备设备还需要进入UB的资源注册、配置、分配、隔离、事件处理和恢复流程才能成为可被系统管理的资源对象。本文范围对于未原生集成完整UB Controller和资源管理接口、同时希望尽量保留既有芯片架构的第三方设备可以由接入侧IO Die或互联SoC承担资源对象映射、管理接口转换和本地控制执行。原生实现完整UB能力的芯片不需要采用相同的适配方式。一、灵衢资源管理面已经定义了基本对象和控制边界公开技术资料中UBFMUB Fabric Manager是UB Domain的管理者负责域内互连、通信和计算资源管理并动态处理运行期事件。UB Controller接受UBFM管理提供远端内存访问、消息通信、资源池化、访问隔离、中断、错误处理和虚拟化等能力UB Switch承担逻辑路由并接受UBFM管理。Entity是UB资源管理中的功能资源对象。域内Entity、Port、内存和通信资源需要完成注册和能力或服务声明UBFM基于全局唯一身份识别和调度资源并动态管理Entity的通信对象身份EID。一个UBPU可以包含一个或多个Entity每个Entity至少具有配置空间并可具有资源空间。围绕EntityUB进一步定义了以下管理机制配置空间面向UBFM和具有Entity使用权的User保存能力、状态和配置信息资源空间面向软件提供中断、功能或服务相关的操作接口。EID用于标识通信对象UPI是Entity所属UB Partition的分区标识收发包时校验UPI不匹配则丢弃Token是访问目标内存段或Jetty等对象的凭据UMMU负责内存地址映射和访问权限校验。Entity产生的USI通过Write类事务写入系统配置的中断地址由目标侧中断控制器、中断管理子系统和UB驱动完成后续处理Type 1和Type 2中断采用不同的向量与表项组织方式。Entity支持池化和虚拟化。管理软件可以完成Entity的注册、使用分配、配置和回收在虚拟化场景中管理面由Hypervisor和UB软件栈控制数据面可以按系统配置直通虚拟机。RAS机制负责错误记录、事件通知、错误处理和复位控制。具体隔离和复位粒度必须与设备真实的硬件边界一致。上述机制构成了UB资源管理的基本对象、访问接口和控制边界。第三方接入方案要做的是把设备现有的功能资源和本地控制机制接入这条管理链路而不是在UB之外重新定义一套管理体系。二、第三方设备的本地管理模型通常与UB不一致现有第三方芯片一般都有成熟的本地管理体系但管理对象和接口未必与UB一致。常见实现包括PCIe配置空间和BAR、Mailbox、私有寄存器、DMA地址窗口、MSI-X、本地中断或门铃、VF或队列组、固件命令、设备级复位、功能级复位以及厂商自定义错误码。这类接口能够满足设备在原有系统中的运行要求但不能直接等价于UB Entity或UB管理接口。例如UBFM管理和分配的是Entity的使用关系第三方设备内部可能只有Function、Queue Group、Namespace、VF或固件服务对象。UB通过配置空间和资源空间管理Entity第三方设备可能通过BAR、Mailbox和私有寄存器完成配置。UB使用EID标识通信对象使用UPI划分访问分区并通过Token、UMMU等机制完成目标资源访问校验和内存地址权限控制第三方设备可能使用Requester ID、PASID、VF、租户ID、IOMMU或自定义DMA窗口。UB的资源隔离、错误归属和复位以Entity、Port或UBPU等对象为边界第三方设备的真实边界可能是整芯片、单控制器、单功能或单队列组。UB要求中断、错误和事件能够关联到相应Entity并进入系统事件处理路径第三方设备可能只提供设备级告警、MSI-X状态或厂商私有错误寄存器。因此第三方设备接入UB时需要建立从“本地资源模型”到“UB可管理资源模型”的映射。该映射应覆盖资源对象、能力描述、配置接口、访问分区、地址映射、中断、复位和错误语义不能只覆盖数据包格式和链路协议。三、IO Die在UB资源管理框架内承担南向适配和本地执行在本文讨论的接入架构中IO Die位于第三方芯片与UB Fabric之间并承载接入侧UB Controller及相应Entity。向上它通过UB Controller、Entity、配置空间、资源空间和事件接口接受UBFM与UB软件栈管理向下它连接第三方设备已有的寄存器、队列、DMA、中断、固件和复位控制。IO Die不替代UBFM也不替代UB OS、UMMU或系统中断子系统。UBFM负责域级资源视图和管理策略UB软件栈、UMMU及中断子系统分别承担设备管理、地址翻译和中断配置等职责。IO Die负责把其控制范围内的管理动作落实到第三方设备并向上报告配置结果、运行状态和错误事件。四、第三方管理适配需要覆盖Entity的完整生命周期4.1 发现和能力声明IO Die上电后识别第三方设备类型、功能数量、队列能力、地址范围、中断能力、复位边界和错误上报能力并据此形成可由UB管理的Entity描述。Entity划分必须以真实的分配、隔离和恢复边界为依据。若两个功能共用同一DMA上下文、同一中断状态或同一复位信号就不应对外声明为完全独立、可单独恢复的Entity。4.2 注册、分配与管理上下文配置Entity的注册、使用分配和域级配置由UBFM及UB软件栈按照协议流程完成。EID、UPI、路由、地址翻译和中断上下文由UBFM、UB Controller、UMMU、UB驱动及系统中断子系统按照各自职责配置。IO Die负责建立Entity与第三方本地功能对象之间的对应关系落实其控制范围内的本地访问门控、队列、中断和复位上下文并返回配置结果。若Entity对外提供内存段或Jetty等访问对象还需按服务模型建立相应的Token、地址和目标资源访问上下文。4.3 配置空间和资源空间适配UB管理面读取Entity能力或修改配置时IO Die将请求转换为第三方设备的寄存器读写、Mailbox命令、队列配置或固件服务调用并统一处理完成状态、超时、非法参数和厂商错误码。资源空间访问或消息调用则需要映射到允许对外开放的本地地址、队列、门铃和服务接口。4.4 池化回收和重新分配Entity从User A回收并重新分配给User B时不能只修改归属标志。IO Die需要停止A的新事务处理未完成事务失效或更新相关Token凭据更新或清除Entity的UPI和本地访问域协同清理相关UMMU或地址翻译上下文关闭本地MMIO、DMA和队列映射屏蔽并清理中断清除门铃和描述符残留状态并在必要且硬件支持时执行Entity级或功能级复位。确认本地状态已清理后才能建立B的新上下文。4.5 RAS、隔离和恢复第三方设备的链路错误、DMA超时、队列阻塞、ECC错误、固件异常、温度告警和复位事件需要转换为UB能够识别的Entity归属、错误级别和影响范围。IO Die可以在本地停止新事务、限制相关访问、屏蔽异常中断并执行设备实际支持的隔离或复位操作。设备恢复后还需要重新检查能力、配置、地址、中断和未完成事务状态并在Entity完成重新注册或重新配置后按照UBFM及系统管理策略恢复服务。IO Die对外声明的隔离和复位粒度必须与第三方设备真实硬件能力一致。五、从UB基础管理机制到第三方接入治理实现说明以下对应关系是本方案在UB资源管理基础机制之上形成的第三方接入实现和治理增强不代表UB规范对所有设备的强制实现要求。其目的是说明IO Die如何利用UBFM、Entity、配置空间、资源空间、EID、UPI、Token、UMMU、中断和RAS等既有接口补齐非原生UB设备的本地执行能力。这套对应关系说明IO Die承担的是UB资源管理模型面向第三方设备的南向适配和本地执行增强。UBFM仍然掌握域级资源视图和管理策略IO Die提供对象映射、接口转换、状态汇聚、异常收敛和恢复执行等设备侧能力。六、以现有NVMe SSD通过UB IO Die接入为例以下以现有NVMe SSD通过UB IO Die接入的一种工程实现为例。具体Entity划分、数据通路和中断模型取决于SSD侧接口与IO Die架构不代表UB原生SSU或其他存储形态。SSD保留NVMe Controller、FTL、ECC、NAND和固件体系IO Die负责其UB资源管理适配。在该实现中IO Die可以保留SSD侧既有队列、DMA、控制命令和错误处理方式同时向UB侧完成以下适配识别SSD控制器及可独立管理的功能依据真实的地址、中断和复位边界映射为一个或多个Entity建立Entity配置空间和必要的资源空间将UB管理请求转换为SSD控制命令和状态查询按照UBFM和系统管理配置建立EID、UPI及本地功能上下文若对外开放内存段、队列或其他目标资源建立相应的访问凭据和地址映射根据服务模型将资源空间访问或消息调用映射到SSD侧控制接口、队列管理、门铃和状态区域实际数据搬运由IO Die数据路径和SSD既有队列协同完成若SSD侧采用MSI-X或本地队列完成机制按照系统设计将完成状态和错误事件汇聚或转换为UB侧中断、事件通知或管理上报在SSD异常时停止新请求对未完成事务执行等待、终止、受控错误返回或恢复后接续避免上游长期等待在控制器恢复后重新检查队列、地址、固件和介质状态完成Entity重新注册或重新配置后按照UBFM及系统管理策略恢复服务。七、结语灵衢社区公开的资源管理框架已经明确了UB域内的管理角色、资源对象和基础机制UBFM负责域级互连、通信和计算资源管理Entity通过配置空间、资源空间、EID、UPI、中断和RAS等机制进入注册、配置和运行管理流程Token、UMMU等机制用于目标资源访问凭据、地址映射和权限校验。对于未原生实现完整UB Controller和资源管理接口的第三方设备IO Die可以承担管理适配和本地执行向上呈现UB能够识别的Entity、能力、状态和事件接口向下操作第三方设备现有的寄存器、队列、DMA、中断、固件和复位资源。IO Die不替代UBFM、UB OS、UMMU或系统中断子系统而是在其管理框架内落实设备侧动作。完成这层适配后第三方芯片才能从“数据可达”进一步进入“资源可发现、可配置、可分配、可隔离和可恢复”的运行状态。这是第三方IO Die接入方案区别于单纯链路桥接方案的主要工程价值。目前相关技术已围绕对象映射、访问控制、事务治理、运行状态监测、异常收敛和恢复重入形成系列方案并正在结合UB IO Die架构设计、仿真和验证计划推进工程化落地。参考资料① 灵衢社区《灵衢资源管理池化、隔离、调度、自愈》② openEuler社区 UnifiedBus / UB OS Component / UB Service Core公开资料③《信息技术 计算互联总线 超节点平等架构互联技术要求》公开技术要求文本本文引用版本仅用于技术机制说明文件属性和最终要求以发布方正式版本为准。