为了不被裁之NVMe-MI oob

NVMe-MI定义了一套带外管理方式,通过MCTP协议在SMBus/I2C或PCIe上进行通信。MI命令执行涉及MI报文的封装和解封,报文包含Header、Data和IC部分,支持响应、控制原语、NVMeMI命令、NVMe管理命令和PCIe命令等多种格式。MCTP报文通过SMBus/I2C传输,头部包含源和目标终端ID、序列号等信息。
摘要由CSDN通过智能技术生成

Nvme-MI

Nvme-MI(Management Interface),定义了一套新的完整的NVMe SSD管理方式,并支持以oob带外管理方式,对NVMe设备进行一些基本的管理。

oob(out-of-band)

带外管理是使用独立于操作系统控制的硬件资源和组件进行操作的管理。带外通信路径通过SMBus/I2C上的MCTP或PCIe VDM上的MCTP从管理控制器到管理终端。与NVMe协议不同,NVMe-MI协议是通过MCTP(Management Component Transport Protocol)协议进行传输的,同时底层物理层支持PCIe或者SMBus/I2C。我们选择SMBUS/I2C来进行研究,好处就是和NVMe协议分离,即使SSD在NVMe看来是故障的,还能有另外一条路径查看SSD状态。

下图为NVMe MI oob协议分层
在这里插入图片描述
包括应用层(application layer)、协议层(protocol layer)、信息传输层(transport layer)、物理层(physical layer)。应用层包括NVM次系统管理程序,以及代表管理程序跟次系统沟通的管理控制器。协议层包括对应每个管理控制器的NVMe-MI接口,NVMe-MI接口会跟NVM次系统的管理端点协调,以执行NVM次系统管理作业。传输层包括管理元件传输协议(MCTP),以及作为与实体层之间接口的MCTP绑定(binding),并支持PCIe与SMBus/I2C绑定。MCTP支持智能硬件设备(intelligent hardware device)之间与管理相关的通讯,NVMe-MI运用MCTP来简化管理控制器与管理端点间的通讯。物理层包括从信息传输层接收资料所需的输出输入口,每1个接口对应1个管理端点,SMBus/I2C接口与PCIe接口的数量分别可配置0或多个。跟PCIe与SMBus/I2C接口对应的管理端点都支持相同的NVMe-MI指令且提供相同的功能,不过PCIe接口支持的资料传输速度远高于SMBus/I2C接口。
在这里插入图片描述
在这里插入图片描述

MI命令执行过程

  1. host将发送消息按照MI的协议规范组成MI报文;
  2. 将MI报文当作MCTP的数据封装为MCTP报文;
  3. 完整的MCTP报文通过I2C链路发给SSD;
  4. SSD收到MCTP报文后,解封MCTP报文得到MI报文;
  5. 解析MI报文后获取发送消息,然后将要回复的数据按照MI协议规范组成MI报文;
  6. 再将回复MI报文当作MCTP的数据封装为MCTP报文;
  7. 再将MCTP报文通过I2C链路发送给host;
  8. host解封MCTP报文,再解析MI报文获取回复消息

NVMe MI报文

NVMe MI报文由一个或多个MCTP数据包的有效负载组成,最大大小为4224字节(即4KiB+128字节)。
在这里插入图片描述
一个完整NVMe MI报文分为3部分,Header,Data和IC(Integrity Check)

Message Header:

byte 0:
[bit 7] IC(Integrity Check) : 带外机制中的所有NVMe MI报文应进行CRC校验,因此,该位应设置为“1”。
[6 : 0] MT(Message Type) : 该字段由MCTP基本规范定义。在所有NVMe MI报文中,应设置为4h。(Refer to the MCTP IDs and Codes specification)

byte 1:
[bit 7] ROR(Request or Response) : Request 为 “0”,“Response” 为 “1”。
[6 : 3] NMIMT(NVMe-MI Message Type) : 指定在Request下NVMe MI报文类型。“0h” 为 “Control Primitive”,“1h” 为 “NVMe-MI Command”,“2h” 为 “NVMe Admin Command”,“4h” 为 “PCIe Command”,不同报文类型下的格式后面说明。
[bit 0] CSI(Command Slot Identifier) : 什么是命令槽?“0h” 为 “Command Slot 0”,“1h” 为 “Command Slot 1”。4.2节有讲

byte 2:
[bit 1] CIAP(Command Initiated Auto Pause) : 指在 “Command Message” 在进入进程状态时,管理终端是否自动暂停。为 “1” 时自动暂停,由管理端点处理。
[bit 0] MEB(Management Endpoint Buffer) : 管理终端缓冲区, 指定报文数据是包含在NVMe MI报文的数据字段中,还是包含在管理终端缓冲区中。此位仅应在支持管理终端缓冲区操作的Command Message(即,在管理终端缓冲区支持的命令列表数据结构中列出的命令消息)中设置为“1”。如果MEB位在任何其他命令消息中设置为“1”,则管理端点应使用指示MEB位的PEL字段以无效参数错误响应进行响应。

Message Data:

byte [N-1:4] : 包含NVMe MI报文的有效负载。此字段的格式取决于NVMe MI报文类型。

Message Integrity Check:

byte [N+3:N] : 完整性检查,如果byte 0中IC位为“1”,则此字段包含根据NVMe MI报文内容计算的CRC。如果IC位清除为“0”,则该字段不包括在NVMe MI报文中,此字段是字节对齐的。参考NVM Express Management Interface Specification文档的3.1.1.1进行设置。

NVMe MI报文分类

下图说明了NVMe MI豹纹的分类情况,主要有请求和响应两大类。在使用oob机制时,请求报文由Management Controller发送到Management Endpoint。这两大类有可以往下继续分,最终会有六种类别
在这里插入图片描述

1. Response Message格式

在这里插入图片描述
头部同NVMe MI报文头部,Status表示与此响应消息相关的状态,Response Body的内容取决于NVMe MI的消息类型和状态。

Status为“00h”时为命令成功完成,成功响应的不同格式取决于NVMe MI消息类型。除此之外的其他值均为响应错误,格式如下(除了“01h”的“More Processing Required”和“04h”的“Invalid Parameter”),具体见“图26-31”。
在这里插入图片描述

2. Control Primitive格式

在这里插入图片描述
Control Primitive 是从管理控制器发送到管理终端的请求消息,用于影响先前发出的命令消息服务或获取命令槽和管理终端的状态。与命令消息不同,控制原语可以在命令槽处于任何命令服务状态时发送,并由管理终端立即处理,且而无需等待先前向该命令插槽发出的控制原语的响应。如果在不等待管理终端响应的情况下发出多个控制原语,则只保证与最后一个控制原语关联的操作和响应。

3. NVMe MI Command格式

在这里插入图片描述
NVMe MI Command定义请求者可能提交的命令消息。

Opcode(OPC):此字段指定要处理的NVMe MI命令的操作码。包含有Read NVMe-MI Data Structure、NVM Subsystem Health Status Poll、Controller Health Status Poll、Configuration Set/Get、Management Endpoint Buffer Read/Write、VPD Read/Write等

具体每一种操作的配置和功能见第五章。其中Configuration Set/Get可以对SMBus/I2C频率、健康状况变化、MCTP传输单元大小等进行查看设置;Management Endpoint Buffer Read命令允许管理控制器读取管理终端缓冲区的内容,此数据在响应数据中返回;Management Endpoint Buffer Write命令允许管理控制器更新可选管理终端缓冲区的内容;Read NVMe MI Data Structure命令请求描述有关NVM子系统、管理端点或NVMe控制器的信息的数据。

4. NVMe Admin Command格式

在这里插入图片描述
NVM Express Admin Command允许使用带外机制向NVM子系统中的任何控制器发出NVMe管理命令。通过带外机制发出的NVMe管理命令可能会干扰主机软件。管理控制器应与主机协调,或仅发出不干扰主机软件或带内NVMe命令(例如,Identify)的NVMe管理命令。(用MI协议规范模拟封装NVMe命令)

对于NVM Express Admin Command Set,mandatory的命令包括Get Feature、Get Log Page、Identify,optional的命令包括firmware activate、firmware image download、Format NVM、Namespace Management、Namespace Attachment、Security Send、Security Receive、Set Feature还有Vendor Specific部分。

利用这些admin命令,管理者就可以远程获取NVMe设备的信息、配置参数或者利用Vendor Specific部分实现特定功能的监控。比如主机开机的情况下,无需登录主机就可以升级固件, 再配合Activate firmware without reset就可以支持远程升级了。实现了这部分接口,可以做的事情还有很多,不过需要注意到很多optional命令有一些潜在的安全风险,实现起来可能需要配合一些措施保证数据的安全性,毕竟数据领域安全第一。

5. PCIe Command

在这里插入图片描述
PCIe Command定义管理控制器可以提交的命令,以访问与NVM子系统中的控制器相关联的内存、I/O和配置地址空间。只能访问映射到指定控制器的地址(例如,这些命令不直接访问主机上的内存)。通过带外机制的PCIe命令可能会干扰主机软件。管理控制器应与主机协调,或仅发出不干扰主机软件或带内NVMe命令(例如 PCIe Configuration Read)的PCIe命令。

Opcode包括有PCIe Configuration Read/Write,PCIe Memory Read/Write,PCIe I/O Read/Write。Controller ID指定此命令所针对的NVMe控制器的控制器ID。

MCTP报文

数据最终的传输是通过MCTP报文来进行的,MCTP报文的格式如下,要注意MCTP规范使用大端排序,而NVM Express规范使用小端排序,这里采用小端字节顺序进行说明,但不会改变物理层上发送字节的顺序。
在这里插入图片描述
Physical Medium Specific Header : 表示用于在特定物理介质上的设备之间传输MCTP数据包的物理寻址和帧信息。此字段中任何子字段或数据的大小和类型由给定介质上MCTP消息传递的相应传输绑定规范定义。我们是通过SMBus/I2C的MCTP

Physical Medium Specific Trailer : 表示在特定物理介质上的设备之间传输MCTP数据包所需的任何其他特定于介质的尾部字段(如果有)。该字段的典型用途是保存为特定介质指定的每包数据完整性字段(例如CRC、校验和等)

MCTP Packet Header:

Header Version : 标识传输消息中MCTP公共字段的格式、物理帧和数据完整性机制。该值在特定介质的规范中定义。

Destination Endpoint ID : 目标终端ID,接收MCTP的EID

Source Endpoint ID : 源终端ID,发送MCTP的EID

SOM : 如果此数据包是消息的第一个数据包,则设置为1b

EOM : 如果此数据包是消息的最后一个数据包,则设置为1b。

Pkt Seq # : (Packet sequence number) (分组序列号)对于跨越多个分组的消息,分组序列号在每个连续分组上增加模4。这允许接收器在消息的开始和结束之间检测到多达三个连续丢失的数据包。尽管如果设置了SOM位,则数据包序列号可以是任何值(0-3),但建议它是来自设置了EOM位的先前数据包的增量模4。在SOM分组之后,分组序列号应通过包含EOM标志的分组为属于给定消息的每个后续分组递增模4。

TO : (Tag Owner) (标记所有者)位标识消息标记是由作为消息源的端点还是由作为消息目的地的端点发起的。为标记所有者位的每个值单独生成和跟踪消息标记字段。MCTP消息类型可以用附加含义覆盖该位,例如使用它来区分“请求”消息和“响应”消息。设置为1b以指示消息源源自消息标记。

Msg tag : 该字段与源端点ID和标记所有者(TO)字段一起标识MCTP传输级别上的唯一消息。其他元素(如MCTP消息数据字段的部分)是否也用于唯一标识消息实例或跟踪消息重试,取决于消息类型。允许源端点将来自多个消息的数据包并发地交织到同一个目标端点,前提是每个消息都有一个唯一的消息标记。当使用请求/响应消息交换且在请求中将标记所有者(TO)位设置为1时,响应者应返回相同的消息标记,并在相应的响应消息中将消息标记所有者位清除为0。对于拆分为多个数据包的消息,来自SOM到EOM的所有数据包的标记所有者(TO)和消息标记位保持不变。
在这里插入图片描述
MCTP的最小传输单元大小为64字节,除了最后一个数据包(EOM位为1b的数据包)中的传输单元外,给定消息中所有数据包的传输单元应具有相同的大小。

SMBus/I2C Transport Binding

MCTP over SMBus/I2C transport binding定义了如何使用SMBus通过物理SMBus或I2C接口传递MCTP报文。所有MCTP事务都基于SMBus块写入总线协议。前8个字节构成数据包头。前三个字段直接映射到 SMBus 功能字段;剩余的报头和有效负载字段映射到SMBus块写入“数据字节”字段。因此,报头中的源从属地址由MCTP指定,而不是SMBus指定。MCTP over SMBus/I2C数据包如下图所示。
在这里插入图片描述
Slave Address : [7:1]SMBus目标从地址:本地SMBus链路的目标设备的从地址;[0]SMBus R/W位:应设置为0b,因为所有MCTP消息都使用SMBus写入事务。

Command Code : SMBus命令代码,SMBus上的所有MCTP消息都使用命令代码0x0F。

Byte Count : 字节计数,该值是字节计数字段后面的字节计数,直到但不包括PEC字节。例如,如果MCTP数据包有效负载长度(从字节9开始)为64字节,则字节中的值计数字段应为69。(69的计数占MCTP数据包有效负载的64字节加上组成SMBus特定报头和数据包的字节的五个字节[字节4到8包括在内])字节计数字段后面的MCTP标头。)

Data Byte 1 : [7:1]SMBus源从地址;[0]对于本地SMBus链路,源设备的从属地址。该位应设置为1b。该值使MCTP能够与IPMI over SMBus和IPMB(IPMI over I2C)协议区别开来。

参考

NVMe-NVM-Express-2.0a
NVM-Express-Management-Interface-1.2
MCTP Base Specification
MCTP SMBus/I2C Transport Binding
大佬写的CSDN
还有其他百度搜索的,自己百度就行了

评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值