【栏目介绍：“玩转OurBMC”是OurBMC社区开创的知识分享类栏目，主要聚焦于社区和BMC全栈技术相关基础知识的分享，全方位涵盖了从理论原理到实践操作的知识传递。OurBMC社区将通过“玩转OurBMC”栏目，帮助开发者们深入了解到社区文化、理念及特色，增进开发者对BMC全栈技术的理解。

欢迎各位关注“玩转OurBMC”栏目，共同探索OurBMC社区的精彩世界。同时，我们诚挚地邀请各位开发者向“玩转OurBMC”栏目投稿，共同学习进步，将栏目打造成为汇聚智慧、激发创意的知识园地。】

在这个信息化时代，服务器和数据中心的管理变得越来越重要。IPMI（Intelligent Platform Management Interface，智能平台管理接口）是一种开放的标准，其核心目的在于通过一种不受操作系统和CPU限制的机制，实现对硬件状态的全面监控与高效管理。本文旨在为读者普及IPMI的基础知识，助力其深入理解并有效运用这一技术。

IPMI 概述

IPMI是由 Intel、DELL、HP 和 NEC 于 1998 年共同提出，并得到了超过 170 家供应商的支持。它提供了一种标准化的方法来监控和管理服务器的物理健康状态，包括温度、电压、风扇速度和电源状态等。其历史与发展简介如下：

• 1998年：IPMI 1.0 版本发布，初步定义了硬件管理的基本功能。

• 2004年：IPMI 2.0 版本发布，引入了多项新特性，如远程管理、安全性增强和 VLAN 支持等。

• 2010年至今：IPMI 不断演进，增加了更多的功能和优化，以满足日益复杂的管理需求。

IPMI 是一个标准化管理接口，主要用于监控和管理计算机硬件。它独立于主机操作系统运行，通常通过基板管理控制器（BMC：一个专用的微控制器，负责处理 IPMI 指令和监控硬件状态）实现。IPMI 提供了一套标准化的命令和协议，用于远程监控系统的状态（如温度、电压、风扇转速等）、执行远程开关机、复位操作，以及获取硬件故障信息等。

IPMI有以下主要功能：

(1) 硬件监控：监测服务器的温度、电压、风扇速度和电源状态等。

(2) 远程管理：通过网络远程控制服务器的启动、关闭和重启。

(3) 事件日志：记录系统事件和警报，帮助诊断和故障排除。

(4) 安全管理：提供安全认证和加密功能，确保管理接口的安全性。

IPMI的应用场景广泛，包括但不限于：

(1) 数据中心管理：监控和管理大规模服务器集群。

(2) 远程 IT 支持：远程诊断和解决问题，无需现场操作。

(3) 物联网 (IoT)：用于管理嵌入式设备和边缘计算设备。

(4) 企业级服务器：确保关键业务系统的稳定运行。

IPMI在实际应用中展现出了显著的优势，但同时也存在一些局限性：‍

• 优势：

(1) 标准化：开放且免费的标准，广泛支持。

(2) 独立性：独立于操作系统和 CPU，适用于多种硬件平台。

(3) 远程管理：强大的远程管理功能，提高运维效率。

• 局限性：

(1) 复杂性：配置和使用 IPMI 需要一定的技术知识。

(2) 性能影响：BMC 的运行可能会对服务器性能产生轻微影响。

IPMI在硬件管理接口方面具有标准化、独立性和远程管理等显著优势，但同时也存在复杂性、性能影响、安全性以及扩展性等方面的局限性。在实际应用中，需要综合考虑这些因素，并根据具体需求选择合适的管理接口方案。

IPMI 的核心是通过 BMC 与系统硬件进行交互，但它本身并不定义具体的物理传输接口，而是依赖于多种传输层协议（如 KCS、BT、SSIF 等）来实现与 BMC 的通信。接下来主要讲解KCS接口相关内容。

KCS接口

KCS （Keyboard Controller Style）是一种用于与 BMC 通信的接口规范，是 IPMI 的一种传输层接口，用于在主机与 BMC 之间传递 IPMI 消息。它定义了主机如何通过系统总线（如 LPC 总线）与 BMC 进行通信。其特点如下：

（1）基于 LPC 总线：KCS 通常在低速的 LPC（Low Pin Count）总线上实现，适用于较老的系统架构。

（2）简单高效：KCS 是一种相对简单的接口，适合需要低延迟和实时响应的场景。

（3）主要用于主机与 BMC 之间的通信：主机可以通过 KCS 向 BMC 发送命令，获取系统状态或执行管理操作。

下面分别对KCS接口原理和协议格式进行介绍。

1、KCS Interface-BMC Request Message Format

请求消息通过KCS接口以write transfer的方式从系统软件发送到BMC。

消息的字节按照特定的格式组织，确保消息能够正确地被BMC解析和处理。

表1 KCS Interface/BMC Request Message Format

• Byte 1: NetFn/LUN

NetFn（Network Function）：NetFn是网络功能代码，用于对通过KCS接口接收到的消息进行功能路由。NetFn字段占用第一个字节的高6位（most significant six bits），范围为6位二进制数，即0x00到0x3F。NetFn字段为BMC提供第一级的消息路由。不同的NetFn值对应不同的功能组。偶数NetFn值：用于向BMC发送请求消息。奇数NetFn值：用于BMC返回的响应消息。

LUN（Logical Unit Number）：LUN是逻辑单元号，用于将消息路由到同一物理接口后的不同逻辑单元。LUN字段占用第一个字节的低2位（least significant two bits），范围为2位二进制数，即0b00到0b11。LUN允许在一个物理接口上存在多个逻辑单元（例如不同的子系统或功能模块），消息可以通过LUN字段被路由到特定的逻辑单元。

注：功能组是指BMC（基板管理控制器）内部不同功能模块的集合（如网络管理功能组，系统控制功能组）。逻辑单元是指在同一接口（如KCS接口）下，可以独立处理消息的多个逻辑实体（如温度传感器，电压传感器）。

• Byte 2: Cmd（Command）

Cmd是命令代码，用于表示在指定NetFn功能下要执行的具体操作，占用第二个字节。Cmd字段与NetFn字段配合使用，BMC根据NetFn找到对应的功能组，然后根据Cmd执行具体的操作。

• Byte 3:N: Data

Data是命令所需的数据部分，包含零个或多个字节的数据，数据的长度取决于具体命令的需求。数据传输顺序通常情况下，按低字节优先（LS-byte first）的方式传递。

2、BMC-KCS Interface Response Message Format

请求消息通过KCS接口以写传输（write transfer）的方式从系统软件发送到BMC。消息的字节按照特定的格式组织，确保消息能够正确地被BMC解析和处理。响应消息格式如下：

• Byte 1: NetFn/LUN

LUN (Logical Unit Number): 逻辑单元号，这是在请求消息中传递的LUN的返回值。NetFn (Network Function): 网络功能码，这是在请求消息中传递的NetFn码的返回值。不过，返回时NetFn值是奇数。

• Byte 2: Cmd

Cmd: 命令码，这是在请求消息中传递的Cmd码的返回值。

• Byte 3: Completion Code

Completion Code: 完成代码，指示请求是否成功完成。成功的完成代码通常表示操作成功，而错误代码则表示操作失败及相关错误信息。

• Byte 4:N: Data

Data: 零个或多个数据字节，取决于具体命令的需求。即使没有数据需要返回，BMC也会返回一个响应以确认请求已收到。

3、 KCS Interface Registers

KCS接口的寄存器映射到系统I/O空间，默认的系统基地址为0xCA2h，寄存器大小为四个字节宽，分别如下：

• 状态寄存器（Status Register）：提供标志和状态位，用于各种定义的操作。

• 命令寄存器（Command Register）：提供端口，用于写入“写控制代码”。

• 数据输入寄存器（Data_In）：提供端口，用于写入数据字节和“请求下一个数据的控制命令”。

• 数据输出寄存器（Data_Out）：提供端口，用于读取数据字节。

(1) 状态寄存器

状态寄存器信息如下表2所示：

表2 状态寄存器

注：上图引用<Intelligent Platform Management Interface Specification Second Generation v2.0 >

状态寄存器（Status Register）：位于I/O地址base+1，为只读寄存器。包含以下位：

• S1 (位7) 和 S0 (位6):

这两个位共同表示KCS接口的当前状态。主机软件需要监控这两个位，以确保与BMC的同步。这些状态位可能指示接口是处于空闲状态、正在传输数据，还是处于其他某种模式。通过检查这些位，软件可以确定何时可以安全地进行读写操作，以及如何响应BMC的请求。

• OEM2 (位5) 和 OEM1 (位4):

这些位保留给BMC实现者或系统集成商自定义使用。具体的用途取决于具体的实现，可能用于特定的系统管理功能或扩展。

• C/D# (位3):

这个位指示最近一次写操作是针对命令寄存器还是数据输入寄存器。值为1表示最近写入的是命令寄存器，值为0表示写入的是数据输入寄存器。这个位有助于软件跟踪其与BMC的交互历史，确保正确的命令和数据序列。

• SMS_ATN (位2):

这个位是一个重要的中断标志位。当BMC有消息要发送、看门狗定时器预超时或事件消息缓冲区满时，该位被设置为1。此外，OEM可以配置在特定的OEM标志被设置时也设置这个位。SMS_ATN位主要用于指示BMC是系统中断的来源，使得系统软件能够及时响应BMC的请求或事件。

• IBF (位1):

输入缓冲区满标志。当系统软件写入命令寄存器或数据输入寄存器时，该位自动设置为1，表示输入缓冲区已满，BMC需要处理这些数据。

• OBF (位0):

输出缓冲区满标志。当BMC写入数据输出寄存器时，设置该位为1，表示有数据可供系统软件读取。

注：这里明确指出了读/写的方向是相对于接口的“系统侧”（即系统软件）而言的。换句话说：读操作是数据从BMC流向系统软件，写操作是数据从系统软件流向BMC。

7:6位是KCS接口的状态位（S1 和 S0），用于指示当前接口的状态，帮助BMC和系统软件保持同步。不同的状态位组合表示不同的工作模式或错误状态。状态位如下表3所示：

表3 状态位

注：上图引用<Intelligent Platform Management Interface Specification Second Generation v2.0 >

• IDLE_STATE (00)：

接口处于空闲状态，表示当前没有数据传输或操作正在进行。

系统软件不应等待或发送任何数据。这是接口的默认状态，表示没有活动发生。

• READ_STATE (01)：

BMC正在向系统软件传输数据包。

系统软件应处于“读取消息”状态，等待接收来自BMC的数据。

• WRITE_STATE (10)：

BMC正在从系统软件接收数据包。

系统软件应处于“写入命令”状态，向BMC发送命令或数据。

• ERROR_STATE (11)：

BMC检测到接口级别的协议违规，或者传输已被中止。

系统软件可以通过“Get_Status”控制代码查询错误的性质，或者简单地重试之前的命令。

注：每当BMC复位（无论是上电复位还是硬复位），状态位会被初始化为“11 - 错误状态。

(2) 命令寄存器

只有当IBF标志被清除时，才可以从系统端写入命令寄存器，因为状态寄存器和命令寄存器是同一个地址。只有WRITE_START、WRITE_END或GET_STATUS/ABORT控制代码可以被写入命令寄存器。

(3) 数据寄存器

进出BMC的数据包通过数据寄存器传递。这些字节包含消息的所有字段，如 Network Function code, Command Byte,以及请求或响应消息所需的任何附加数据。只有在IBF标志被清除时，才能从系统端写入Data_In寄存器。必须设置OBF标志为1才能读取Data_Out寄存器（请参见状态寄存器）。

(4) KCS控制代码和状态码

Kcs控制码如下表4所示：

表4 Kcs控制码

注：上图引用<Intelligent Platform Management Interface Specification Second Generation v2.0 >

KCS 接口状态码在 KCS 接口的通信过程中使用，主要用于指示当前接口的状态或发生的错误。具体来说，当主机通过 KCS 接口与 BMC（基板管理控制器）进行通信时，会使用这些状态码来报告操作的结果。Kcs接口状态码如下：

表5 Kcs接口状态码

注：上图引用<Intelligent Platform Management Interface Specification Second Generation v2.0 >

4、KCS接口的基本通信流程

接下来介绍KCS（Keyboard Controller Style）接口的系统管理软件（SMS）与基板管理控制器（BMC）之间的通信过程，重点介绍写传输（Write Transfer）和读传输（Read Transfer）的流程以及相关的状态和控制机制。

• 写传输（Write Transfer）：

系统管理软件（SMS）首先通过写传输向 BMC 发送请求消息（Request Message）。每个写操作（控制码或数据字节）到 Data_In 寄存器，都会使 IBF（Input Buffer Full，输入缓冲区满）标志置位，触发 BMC 读取对应的控制码或数据字节。BMC 处理完成后，如果接口使用中断（Interrupt），BMC 会向 Data_Out 寄存器写入一个虚拟值 00h，并更新状态寄存器，触发 OBF（Output Buffer Full，输出缓冲区满）中断，通知系统管理软件。

• 读传输（Read Transfer）：

系统管理软件向Data_In 寄存器写入读控制码（READ Control Code），使 IBF 置位。BMC 响应读控制码，向 Data_Out 寄存器写入数据字节。如果接口使用中断，写入数据字节时也会触发 OBF 中断。

• 配对请求与响应：

请求消息通过写传输发送给BMC，响应消息通过读传输从 BMC 读取。写传输和读传输共同组成一个完整的命令/响应事务。

• IDLE_STATE（空闲状态）：

接口在成功完成一个完整的命令/响应事务后会自动返回到空闲状态。

这意味着系统管理软件不需要显式地使用GET_STATUS/ABORT 命令来返回到空闲状态。

• ERROR_STATE（错误状态）：

如果发生错误，系统管理软件可以选择简单地重试命令，或者发送一个“已知良好”的命令来清除错误状态。这表明当出现错误的时，可以发送新的命令来清除之前错误的寄存器状态。

接口设计允许在输入缓冲区为空时随时启动或重新启动命令传输。

注：已知良好的命令目的是确认系统管理软件（SMS）与基板管理控制器（BMC）之间的通信是否正常，或者在检测到错误状态（如 ERROR_STATE）时，通过发送一个简单且不会导致错误的命令来清除错误状态。（如获取BMC状态，简单的查询命令）。

• OBF中断：

在写传输过程中，BMC 通过向 Data_Out 寄存器写入 00h 虚拟值，并更新状态寄存器，触发 OBF 中断，通知系统管理软件。在读传输过程中，BMC 向 Data_Out 寄存器写入数据字节时也会触发 OBF 中断。

KCS的HOST TO BMC流程图如下：

注：上图引用<Intelligent Platform Management Interface Specification Second Generation v2.0 >

1) 初始等待阶段：等待IBF=0清OBF，SMS首先等待输入缓冲区（IBF）为空（IBF=0），表示BMC已经准备好接收新的命令或数据，同时清除OBF初始化环境。确保之前的操作已经完成，避免数据冲突。

2) 发送WR_START命令，等待IBF等于0，SMS向命令寄存器发送一个控制码（WR_START），表示写操作的开始。通知BMC即将开始写操作。等待IBF等于0，表示BMC已经接收了WR_START命令，此时主机此时不能向Data_In寄存器里面写数据，确保BMC已经处理完命令。

3) 查询WRITE_STATE，SMS检查BMC是否处于WRITE_STATE状态，判断BMC是否准备好接收数据。

4) 清除OBF，在发送数据之前，SMS清除输出缓冲区（OBF），确保缓冲区的状态干净，避免旧数据干扰。

5) 发送数据字节，SMS将数据字节写入数据寄存器，即向BMC传输实际的数据。

6) 等待IBF=0，表示BMC已经接收了数据字节,确保BMC处理完数据。

7) 继续查询WRITE_STATE并判断是否为最后一个字节，如果当前字节不是最后一个字节，则循环操作步骤（5）（6）（7）。如果是最后一个字节，则SMS向命令寄存器发送WR_END命令，表示写操作结束。

8) SMS最后会通过发送一个字节数据到DataIn，而BMC在读取数据字节之前，BMC就会先将自身状态设置为READ_STATE，随后开始读流程。   

思考点

1. 为什么HOST 写完最后一个字节后还要再 data byte to DATA ？

答：HOST写完之后要进入读阶段，但是BMC并不知道什么时候进入读阶段，需要再往BMC写入一个字节，表示通知BMC此时要从写阶段转换到读阶段。 （之前HOST写入WR_END仅仅表示写入结束，并不能代表告诉BMC准备进入阶段转换。）                                                                         

KCS的BMC TO HOST流程图如下：

注：上图引用<Intelligent Platform Management Interface Specification Second Generation v2.0 >

1) SMS的读流程中首先要等到IBF=0，即输入缓冲区没有数据。

2) 如果此时是读流程，则需要等待OBF=1，表示BMC已将数据放入输出缓冲区，等待HOST读取数据。

3) Host按字节读取数据。

4) 每次读取完毕后，Host发送READ请求读取下一个数据。

5) 在BMC发送完最后一个数据字节到DataOut后，BMC会将状态设置为IDLE_STATE，此处可以理解为假IDLE。

6) HOST在读取完最后一个字节后，会判断此时状态，正常情况下，BMC处于IDLE状态。HOST还要读取最后一个字节（等OBF等于1，并从输出缓冲区读），此后阶段才会变成IDLE。

2. 为什么BMC发送完毕最后一个字节后进入IDLE状态后，HOST端读取完毕最后一个字节后，还要再等OBF等于1，再读一次？

答：之前进入IDLE状态是BMC发送完数据到Data_OUT里后，但是并不清楚主机是否成功接收处理了最后一个字节数据。因此需要确认数据传输完成，BMC会发送一个虚拟字节00h到输出缓冲区，只有当HOST读取了输出缓冲区中的最后一个虚拟字节，BMC才能确认数据传输已经完成。

注：无论是Host To BMC还是BMC To Host，只要遇到Error Exit的情况，即当前的通讯是异常的，可以选择重发此包，但要保证状态寄存器复位，可以正常进行下一次的传输。或者也可参考IPMI规范中关于异常处理的部分，详情请看IPMI规范。

本期内容主要讲解了IPMI基础知识以及其中的Kcs接口知识，随着云计算和物联网的发展，IPMI 将继续演进，增加更多的管理和安全功能。未来的 IPMI 标准将更加智能化、自动化，更好地适应多样化的应用场景。

常见问题解答

Q1：如何判断服务器是否支持 IPMI？

通常，服务器的BMC 模块会提供 IPMI 支持。可以通过服务器的用户手册或 BMC 管理界面进行确认。

Q2： IPMI 是否需要专门的软件？

IPMI 可以通过多种工具（如 ipmitool、Web 界面等）进行管理，无需安装专门的软件。

LAN 接口：通过网络进行远程管理。

欢迎大家关注OurBMC社区，了解更多BMC技术干货。

OurBMC社区官方网站：

https://www.ourbmc.cn/