《NVM-Express-1_4-2019.06.10-Ratified》学习笔记（8）

8 Feature（特性）

8.1 固件升级过程

固件升级通过重启激活的过程是：

1. 主机发一个Firmware Image Download命令，下载固件映像版本到controller。可能有多个固件映像版本的部分需要下载，因此每个固件映像版本部分的下载偏移量在Firmware Image Download命令中指定。Firmware Image Download命令中提供的数据应该符合Firmware Update Granularity，如在Identify Controller数据结构中或固件升级可能会失败的固件升级粒度；

2. 固件下载到controller之后，下一步是由主机提交一个Firmware Commit命令。Firmware Commit命令验证最后下载的固件映像版本有效性并提交映像版本到将要使用的固件槽位里。固件映像版本不从偏移量为0的位置启动，包括缺口，或包括区域重叠被认为是无效的。controller可以采用额外的供应商指定的手段（例如：checksum，CRC，密码哈希或数字签名）来确定固件映像版本的有效性：

a. Firmware Commit命令可能也被用于激活之前提交的固件槽位中的固件映像版本；

3. 最后一步是执行重启，来触发Firmware Commit命令中指定的固件槽位域里的固件映像版本激活。重启可以是一个NVM Subsystem Reset，Conventional Reset，Function Level Reset，也可以是Controller Reset（把CC.EN的值从1变成0）：

a. 有些场景Conventional Reset 或 NVM Subsystem Reset需要激活一个固件映像。这个要求由Firmware Commit命令特定的状态（参考5.11.1章节）来表明的；

4. 重启完成之后，主机软件重新初始化controller。包括重新申请I/O提交队列和I/O完成队列。请参考7.6.1章节。

不用重启的固件升级和激活步骤：

1. 主机发一个Firmware Image Download命令，下载固件映像版本到controller。可能有多个固件映像版本的部分需要下载，因此每个固件映像版本部分的下载偏移量在Firmware Image Download命令中指定。Firmware Image Download命令中提供的数据应该符合Firmware Update Granularity，如在Identify Controller数据结构中或固件升级可能会失败的固件升级粒度；

2. 主机提交Firmware Commit命令，带上值为011b的Commit Action指定映像版本不重启的情况下立即激活。下载的这个映像版本应该替换掉固件槽中的映像版本。如果从最后一次重启或Firmware Commit命令之后没有下载的映像版本（例如：第一步被跳过），那么controller必须验证和激活指定槽位中的映像版本。如果controller开始激活映像版本，如果开启了Firmware Activation Notices，任何受新固件影响的controller都向主机发送Firmware Activation Starting异步事件（请参考Figure287）：

a. Firmware Commit命令也可以用于激活之前提交的固件槽位中的固件映像版本；

3. controller完成Firmware Commit命令。以下是应对某些错误场景的操作：

a. 如果固件映像版本无效，那么controller报告响应的错误；

b. 如果固件激活未成功是因为激活固件要求的Controller Level Reset原因，那么controller报告Firmware Activation Requires Controller Level Reset的错误，在下一次Controller Level Reset再使用这个映像版本；

c. 如果固件激活未成功应因为激活固件要求的NVM Subsystem Reset原因，那么controller报告Firmware Activation Requires NVM Subsystem Reset的错误，在下一次NVM Subsystem Reset时再使用这个映像版本；

d. 如果固件激活未成功应因为激活固件要求的Conventional Reset原因，那么controller报告Firmware Activation Requires Conventional Reset的错误，在下一次Conventional Reset时再使用这个映像版本；

e. 如果固件激活未成功因为固件激活时间将超过在Identify Controller数据结构中报告的MTFA值，那么controller报告Firmware Activation Requires Maximum Time Violation的错误，这种情况，为了激活固件，需要重新提交Firmware Commit命令和使用一个重启激活映像版本。

在Firmware Commit命令的提交之后，准备激活固件映像版本，在这个Firmware Commit完成之前，如果controller转换到了D3cold状态（请参考PCIe基础规格说明书），那么controller恢复运行用的既不是Firmware Commit命令正要激活的固件映像版本也不是原来已经激活的那个固件映像版本。

如果固件不能被成功加载，那么如果可能的话，controller应该还原回当前的最近的已激活的固件槽位固件映像版本或那个只读的基线固件映像版本，并且作为一个Firmware Image Load Error的异步事件表明这个故障。

如果主机覆盖写激活固件槽位中的固件，那么这个已经激活的固件映像版本可能不再可用。因此，任何需要使用该固件槽位的操作(例如，循环加电重启控制器)都可以使用当前位于该固件槽位中的固件映像。

主机软件不能同时的升级多个固件映像。下载完一个映像，主机软件在下载其他的固件映像之前提交Firmware Commit命令。第一个Firmware Download命令的处理如果晚于Firmware Commit命令完成，如果还有未下载完的映像部分，剩下的部分将导致被controller丢弃。如果固件下载和Firmware Commit命令的完成之间发生了重启，那么controller应该丢弃下载映像的所有的部分。

8.2 元数据处理

Controller可以支持每个逻辑块的元数据。元数据是在每个逻辑块基础上分配的附加数据。对主机如何使用元数据区没有要求。元数据最普遍的用法之一是传达端到端保护信息。

元数据可以在controller到主机和主机到controller任意一个方向上传送，当格式化namespace时选择使用机制。

传送元数据的第一个机制是相应的元数据作为逻辑块的一个连续的部分。元数据紧跟对应逻辑块的后边被传送，形成扩展的逻辑块。这种机制的插图见图Figure 449。在这种情况，逻辑块数据和逻辑块元数据二者都被PRP1和PRP2指针所指向（或SGL Entry 1，如果使用了SGL的话）。

传送元数据的第二种机制是元数据作为一个单独的数据缓冲区。这种机制的插图见图Figure 450。这种情况，元数据被Metadata Pointer元数据指针所指向，而逻辑块数据被Data Pointer指针所指向。命令中元数据使用PRPs时，要求元数据是物理上连续的。命令中的元数据使用SGLs时，不要求元数据是物理上连续的。

每个namespace被格式化时都必须选择传送机制的其中一种机制；不支持传送这部分元数据使用一种机制，而传送另一部分元数据使用另一种机制。

如果使用了端到端的数据保护，那么每个逻辑块的Protection Information域都包含在元数据中。

8.3 端到端数据保护

提供从应用到NVM媒介以及再回到应用自身的健壮的数据保护，可以使用端到端数据保护。如果开启了这个可选机制，那么附加的保护信息（例如CRC）就被加到逻辑块，可以由controller和/或主机软件判断，以确定逻辑块的完整性。如果存在这个附加的保护信息，基于namespace的格式，它可以是元数据的第一个八字节或者元数据的最后八字节。对于多于八字节的元数据格式，如果保护信息包含在元数据的第一个八字节里，那么CRC不涵盖任何元数据字节。对于保护信息包含在元数据的最后八字节中的这种多于八字节的元数据格式，CRC涵盖除了这最后八字节之外的所有的元数据字节。【注：也就是说CRC只计算它前边的字节。如果CRC位于元数据的最前边八字节，那么其他元数据字节都在CRC之后，计算CRC时不计算CRC后边的这些元数据字节；如果CRC位于元数据最后，那么计算CRC时就把前边的元数据计算到CRC里边了】。如8.2章节描述，元数据和这些保护信息或许是与逻辑块数据连续的，或许是存储在单独的缓冲区里。

在企业级实施里使用的最通用的数据保护机制是SCSI Protection信息，通常称为Data Integrity Field（DIF）和Data Integrity Extension（DIX）。这两个机制之间最主要的区别是保护信息的位置。在DIF中，保护信息创建扩展逻辑块且与逻辑块数据是连续的。而DIX中，保护信息存放于单独的缓冲区中。本规格说明书定义的端到端数据保护机制从功能上兼容DIF和DIX二者。通过配置元数据与逻辑块数据连续实现DIF功能（如图Figure449所示），而通过配置元数据和数据在单独的缓冲区里实现DIX功能（如图Figure450）。

NVMe支持SBC-3中指定的定义在SCSI Protection信息模型中的相同的端到端保护类型。当格式化namespace时，端到端数据保护的类型（例如Type1、Type2或Type3）是可选的，并在Identify Namespace数据结构（参考Figure245）中记录。

保护信息格式如图Figure 451所示，包含在与每个逻辑块对应的元数据中。Guard域包含一个通过逻辑块数据计算的CRC-16。CRC-16的计算公式定义在SBC-3中。除了RCR-16之外，DIX也指定一个可选的IP checksum，NVMe接口不支持这个。Application Tag是不透明的数据域，不能被controller理解，它可以用于禁止保护信息的检查。Reference Tag把逻辑块数据与一个地址关联起来，防止被误用或者乱序逻辑块传输。类似于Application Tag，Reference Tag也可以用于禁止保护信息的检查。

8.3.1 The PRACT Bit

作为读和写命令的副作用执行的保护信息处理由命令中的Protection Information保护信息活动(PRACT)位控制。【注：a side effect术语是什么概念？这里被写成副作用了】

8.3.1.1 Protection Infomation和Write Commands

图Figure 452提供了一些保护信息处理作为写命令副作用出现的例子。

如果namespace没有带端到端数据保护格式化，那么逻辑块数据和元数据从主机到NVM传送不带有由控制器相关处理的保护信息。

如果namespace带保护信息格式化，PRACT位被清0，那么逻辑块数据和元数据，包含保护信息，还可能包含额外元数据，从主机缓冲区到NVM被传送（即：元数据字段在NVM和主机缓冲区中保持相同的大小）。当逻辑块数据和元数据透传到controller时，保护信息被校验。如果保护信息校验被发现错误，命令带着检测到错误的状态错误状态码结束（例如：End-to-end Guard Check Error, End-to-end Application Tag Check Error, or End-to-end Reference Tag Check Error）。

如果namespace格式化带保护信息并且PRACT位设置成1，那么：

1. 如果namespace格式化时，元数据大小【Metadata Size】等于8（参考Figure 246），那么逻辑块数据从主机缓冲区到controller传送。当逻辑块数据透传到controller，controller生成和追加保护信息到逻辑块数据尾部，逻辑块数据和保护信息被写入到NVM（元数据不驻留在主机缓冲区内）。

2. 如果namespace格式化时，元数据大小【Metadata Size】大于8，那么逻辑块数据和元数据从主机缓冲区到controller被传送。当元数据透传到controller，controller覆盖写这个保护信息，保护信息属于元数据的一部分。逻辑块数据和元数据都被写入到NVM（在NVM中和主机缓冲区中，元数据域保持同样的大小）。在元数据内部保护信息的位置是namespace格式化时配置的（请参考Figure 245的DPS域）。

8.3.1.2 Protection Infomation和Read Commands

Figure 453 提供一些保护信息处理例子，可能产生读命令处理的副作用。

如果namespace格式化时设置了带保护信息，PRACT的bit位被清0，那么逻辑块数据和元数据被controller从NVM中读出并传递到主机缓冲区，元数据包含保护信息和其他可能的主机元数据（元数据域在NVM中和在主机缓冲区中保持相同的大小）。当逻辑块数据和元数据透传到controller时，元数据内的保护信息被校验的。如果保护信息被校验发现错误，命令结束，返回错误状态码（End-toend Guard Check Error, End-to-end Application Tag Check Error, or End-to-end Reference Tag Check Error）。

如果namespace格式化时，设置带保护信息，PRACT的bit为被设置为1，那么：

a）如果namespace格式化时设置的元数据大小（Metadata Size）等于8（参见Figure246），逻辑块数据和元数据由controller从NVM中读取。当逻辑块和元数据透传到controller时，保护信息被校验，如果保护信息被检测到错误，命令结束，返回探测到的错误码状态（End-toend Guard Check Error, End-to-end Application Tag Check Error, or End-to-end Reference Tag Check Error）。处理完保护信息之后，controller只向主机发送逻辑块数据。

b）如果namespace格式化时，设置Metadata Size大于8，这种情况controller从NVM中读逻辑块数据和元数据，元数据包括保护信息和附件的主机格式的元数据。当逻辑块和元数据透传到controller时，嵌入在元数据中的保护信息被校验，如果保护信息被检测到错误，命令结束，返回探测到的错误码状态（End-toend Guard Check Error, End-to-end Application Tag Check Error, or End-to-end Reference Tag Check Error）。处理完保护信息之后，controller把逻辑块数据和元数据交给主机，嵌入在元数据中的保护信息不做任何变化。（元数据在NVM中和主机缓冲区中大小保持一样）

8.3.1.3 Protection Infomation for Fused Operations

组成的融合操作命令在保护处理方面与单个命令保护处理过程是相同的。

8.3.1.4 Protection Information和Compare命令

图Figure 454 展示保护信息处理导致Compare命令可能产生的额外处理。Compare命令处理同时涉及Write和Read命令，作为Compare命令的一部分，从主机向controller传递的数据和保护信息，保护信息由controller执行校验，与controller执行Write命令保护信息检查并行。Compare命令的另一部分，从NVM媒介中向controller传送数据和保护信息，controller执行保护信息校验与Read命令保护信息检查并行。

8.3.1.5 Control of Protection Infomation Checking - PRCHK

保护信息的校验包括controller如下执行的一系列操作。如果命令中Protection Infomation Check（PRCHK）域的第二位bit2设置为1，controller将保护信息Guard域与逻辑块数据计算的CRC-16进行比较。如果PRCHK的第一位bit 1被设置为1，controller将保护信息Application Tag域的未被屏蔽位与命令中Logical Block Application Tag（LBAT）域进行比较。如果命令中Logical Block Application Tag Mask（LBATM）域某bit位被设置为0，相应的信息保护Application Tag域的那个bit位屏蔽掉。

对于Type 1保护，如果PRCHK域的bit 0被设置为1，controller将保护信息Reference Tag域与计算的reference tag进行比较。为命令的第一个LBA计算的reference tag值，包含在命令的Initial Logical Block Reference Tag（ILBRT）或Expected Initial Logical Block Reference Tag（EILBRT）域中。如果namespace被格式化为Type 1或Type 2保护，计算出的引用标记对每个后来的逻辑块是递增的。如果namespace被格式化成Type 3保护，对于每个后续逻辑块的引用标记都与初始引用标记保持相同。不像SCSI Protection Infomation Type 1 保护那样暗中使用LBA的最小有效四字节，NVMe使用Type 1保护时，controller总是使用ILBRT或EILBRT域，并要求主机软件来初始化ILBRT或ELBRT域到LBA的最小有效四字节。Type 1保护，controller应该校验ILBRT域或EILBRT域是否正确；如果值与LBA最小有效四字节不匹配，controller结束这个命令，返回非法保护信息的状态。

对于Type 2保护，如果PRCHK域的第0位被设置为1，controller将每个逻辑块的保护信息引用标记域与计算的引用标记进行对比。计算的引用标记对每个后续的逻辑块都递增。为第一个命令的LBA计算的引用标记值，是命令中ILBRT或EILBRT域内的值。主机软件可以设置ILBRT和EILBRT域为任意值。

对于Type 3保护，如果PRCHK域的第0位被设置为1，这个命令应该被终止，返回非法保护信息状态，也可以在命令中Invalid Field状态终止命令。当使用Type 3保护时，因为计算的引用标记保持不变，所以controller可以忽略ILBRT和EILBRT域。

保护校验可以不管命令中的PRCHK域的状态，作为保护信息Application Tag和Reference Tag域值的一个额外处理，关闭它。如果namespace格式化为Type 1或Type 2保护，当保护信息Application Tag的值是0xFFFF时，不论PRCHK域的状态如何，所有保护信息校验被关闭。如果namespace格式化为Type 3保护，当保护信息Application Tag的值是0xFFFF和保护信息Reference Tag值是0xFFFFFFFF时，不论PRCHK域的状态如何，所有保护信息校验被关闭。

插入的保护信息包括Guard域中计算的CRC-16，Application Tag域中LBAT字段值，以及Reference Tag域中计算的引用标记。