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域中計算的引用標記。