NVMe 自問自答題庫：Security 與 Lockdown
read more
NVMe 自問自答題庫：Security 與 Lockdown
NVMe · Q1–328
NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4
Q237–Q245
Security 與 Lockdown
Security Send／Receive 承載協定資料；Lockdown 限制命令或 Feature。先分清資料交換結果與禁止範圍，再討論 reset 及斷電持續性。
每個問題都接著完整解說，依內容帶讀欄位、比較機制或追蹤流程。先看本冊總覽，再沿問題閱讀；必要條件與正常路徑直接顯示。所有數字案例均為教學假設；Status 以 SCT/SC 表示，代碼後的 h 代表十六進位。
- SCT
- Status Code Type，完成狀態代碼類型
傳輸成功、協定成功與允許執行
NVMe Success 不自動等於認證成功；被鎖定 Feature 的 Get 也不自動被禁止。
| 問題 | 需要的資訊 | 結果所在位置 |
|---|---|---|
| 資料有沒有交換 | Security CQE | NVMe 命令結果 |
| 安全操作是否成功 | SECP、SPSP、payload | 所選協定定義 |
| 命令是否被禁止 | IFC、CSEL、SCP、清單 | Lockdown 及目標 CQE |
| 斷電後是否保留 | CSEL 與 LDPE | 範圍專屬規則 |
- CQE
- Completion Queue Entry，佇列中的完成項目
舉例看懂：CSEL=0、LDPE=1 的禁止可跨 Power Cycle 保留；CSEL=1／2 不能只因 LDPE=1 就取得同樣持續性。
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1
需要時回顧本篇名詞
- Controller / namespace
- controller 接收命令並管理存取；namespace 是命令可指定的一份邏輯儲存空間。NVM subsystem 則包含 controller 與非揮發儲存資源，同一 subsystem 可以有多個 controller。
- SQ / CQ / SQE / CQE
- Submission Queue（SQ）是提交佇列，Completion Queue（CQ）是完成佇列；SQE 與 CQE 分別是其中的一筆命令及完成項目。QID 識別 queue，CID 區分同一 SQ 中尚未完成的命令，NSID 則識別 namespace。
- Register / Identify / Feature / Log
- Register 提供可存取的控制或狀態資訊；Identify 查詢物件的能力與屬性；Feature 用來讀取或變更工作設定；Log Page 回報特定種類的狀態或紀錄。FID、LID、CNS、CSI 則分別用來選擇 Feature、Log Page、Identify 資料結構及命令集。
- index / offset / zero-based
- index 指出清單中的第幾筆，通常從 0 起算；offset 表示與起點相隔多遠，解讀時必須確認單位。若數量欄位採 zero-based 編碼，實際數量等於欄位值加 1；但不是所有欄位看到 0 都要加 1。Dword 是 4 bytes，1 byte 是 8 bits。
- Scope / reset / retention
- scope 表示操作影響哪些物件；retention 表示狀態是否保留。清除 CC.EN 所觸發的 Controller Reset，是 Controller Level Reset（CLR）的一種。同屬 CLR 的不同觸發方式，仍可能採用不同的 Register 保留規則。
本冊題目
- Q237 · 如何確認 Security Send／Receive 與實際協定支援？
- Q238 · Security Protocol、欄位或資料長度不合法時如何處理？
- Q239 · Security 資料傳輸失敗應如何區分 Status 與協定錯誤？
- Q240 · Security 狀態如何影響其他 Admin Command？
- Q241 · Reset 與 Power Cycle 後 Security 狀態是否保留？
- Q242 · Lockdown 如何限制指定 Command 或 Feature？
- Q243 · 執行被 Lockdown 禁止的命令或 Feature 應如何回應？
- Q244 · Lockdown Log 的一般與增強格式如何解讀？
- Q245 · Reset 與 Power Cycle 後 Lockdown 是否保留？
Q237 如何確認 Security Send／Receive 與實際協定支援？
跟著解說理解
NVMe 命令支援與特定安全協定支援是兩層能力，先確認前者，才能安全解讀後者的回覆。
1. 要查哪個對象、哪份資料
OACS 描述 controller 的命令能力；協定探索回覆才說明它能處理哪些 SECP。
查 Identify.OACS 的 Security Send／Receive 支援，並核對 Commands Supported and Effects。
Security Receive 使用 SECP=00h 探索支援協定；這次查詢不需要先送 Security Send。
2. 查詢順序與回覆判讀
先探索，再依所選協定配置 SPSP、NSSF 與資料長度，後續 Send／Receive 配對依協定定義。
NVMe 成功表示命令完成；協定清單指出可繼續使用的安全協定，不表示已完成認證。
3. 證據不足或不一致時怎麼判斷
Security Receive 指定不支援 SECP 必須 Invalid Field in Command；完全不支援 Opcode 則是另一層命令支援問題。
Identify、效果 Log 與探索結果應一致，但不能因 Opcode 受支援就要求每個 SECP 都成功。
先檢查失敗出在 NVMe 命令層，還是選到未支援的安全協定。
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q238 Security Protocol、欄位或資料長度不合法時如何處理？
跟著解說理解
必須分清外層 NVMe 欄位與內層安全資料，否則容易期待錯的 Status。
1. 先區分是哪一種失敗
SECP、SPSP、NSSF 與 DPTR／長度都屬查證範圍，但 payload 格式由協定定義。
Receive 的 AL 與 Send 的 TL 依 Security Protocol In／Out、INC_512=0 的定義使用；不能當成 NVMe 一般 zero-based Dword 數。
Receive 不支援 SECP、Send 使用保留 SECP 須 Invalid Field。內層認證失敗可能以協定 payload 表示，不能全部改寫成 Invalid Field 或 Access Denied CQE。
2. 用哪些資料確認原因
先查 SECP 探索結果與 NVMe 命令支援，再選具體協定。
先核對 NVMe 欄位與 buffer 長度，再解析協定內容；NSSF 只在 EAh 的指定用途下有定義。
3. 結果與後續驗證
合法傳輸取得對應資料或協定回覆；應按協定結果決定認證或安全操作是否成功。
對同一測試記錄外層 CQE 與內層 result，避免把兩者混為一個錯誤碼。
先按 AL／TL 的單位核對傳輸長度與 buffer 容量，確認資料已完整送達後，再依安全協定的回覆檢查認證資料。
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q239 Security 資料傳輸失敗應如何區分 Status 與協定錯誤？
跟著解說理解
資料根本沒有正確傳送，與資料送到後協定拒絕，是不同故障階段。
1. 先區分是哪一種失敗
先看 NVMe 命令，再看所選安全協定；同一個安全動作可能涉及多筆 Send／Receive。
Data Transfer Error 表示命令資料傳輸問題；安全結果可能另外以協定欄位回報，不能只靠字面上的「Security」決定 Status。
未支援欄位、傳輸錯誤、內部錯誤與認證拒絕各有不同前提；沒有「所有安全失敗都回同一 Status」的規則。
2. 用哪些資料確認原因
保存完整 SQE、DPTR、長度、CQE 與有效的 Receive payload。
- SQE
- Submission Queue Entry，佇列中的命令項目
先檢查 CQE 是否允許信任回傳資料，再依協定解碼；失敗傳輸的舊 buffer 內容不能當新回覆。
3. 結果與後續驗證
成功 CQE 只證明該 NVMe 命令成功完成，還需讀協定結果才知道操作是否獲准。
將兩層結果與先後順序對回原始 request，避免讀到上一個 exchange 的結果。
先檢查是不是把成功傳輸的「協定拒絕」誤認成 DMA 失敗。
- DMA
- Direct Memory Access，裝置直接存取記憶體
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q240 Security 狀態如何影響其他 Admin Command？
跟著解說理解
安全協定可能限制其他操作，但不能用一個抽象的「Locked」推論所有 Admin 都被禁止。
1. 機制與適用範圍
影響範圍由協定、保護對象與 NVMe 明定互動共同決定。
Security Send／Receive 傳送協定；Lockdown 是另一个命令禁止機制；Namespace Write Protection 又控制另一種存取狀態。
2. 用操作與結果理解
確認實際 SECP／安全狀態、Lockdown Log，以及適用的 Security Personality 設定。
先判斷被拒命令與範圍，再確認哪一項機制要求拒絕，最後對照該機制指定的 Status。
被允許的查詢仍可能正常運作；解除一種限制不保證其他限制一起解除。
3. 容易誤判的地方
不能把所有拒絕都要求回 Command Prohibited by Lockdown；只有符合 Lockdown 條件才使用該通用 SC23h。
原始協定回覆、Lockdown 清單與命令行為要分層吻合，不能混用安全狀態名稱。
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q241 Reset 與 Power Cycle 後 Security 狀態是否保留？
跟著解說理解
原問題必須指定「哪個安全協定的哪個狀態」，才會有可驗證的保留答案。
1. 先界定觸發方式與影響對象
長期金鑰、持久鎖定設定、暫時 session 與待取的 Receive 資料，不是同一種狀態。
記錄 SECP、協定版本、操作前狀態與 Reset 來源；三份 NVMe 規格只提供其明定的傳輸邊界。
2. 哪些狀態改變，恢復後怎麼處理
Base 明定失聯或 CLR 可能不保留 Security Receive 資料；這不等於永久設定被擦除。
恢復後重新建立需要的交換並查詢狀態，再依協定確認是否需重新認證。
正確結果是符合已指定協定的保留規則，而不是所有狀態一律保留或一律清空。
3. 重設或斷電時，要確認什麼
| 觸發方式 | 這項操作或狀態會如何變化 |
|---|---|
| Controller Reset 後是否保留或繼續？ | CLR 後 Security Receive 待取的結果可能不保留。安全鎖定、認證 session 與金鑰的持續性由所選協定決定，不能把失去傳輸結果解讀成自動解鎖或清除金鑰。 |
| NVM Subsystem Reset 後是否保留或繼續？ | Subsystem Reset 後重新確認通訊及協定狀態。NVMe Base 不給所有 Security Protocol 一個共同的認證或鎖定保留答案，因此測試須先指定協定與狀態。 |
| Power Cycle 後是否保留或繼續？ | Power Cycle 後不能只因 NVMe queues 已重建，就推論安全狀態回到未鎖定。以協定的持久設定、session 規則與查詢結果判斷；未指定協定時，結論只能是 NVMe 三份來源未定義。 |
4. 如何驗證保留或恢復結果
協定未指定時，不得捏造固定 Status、解鎖結果或金鑰處理；應明確標示來源未定義的部分。
把傳輸重新初始化、session 重建與持久設定驗證拆成三項，比單看命令成功更可靠。
先檢查題目中的「Security 狀態」究竟指哪個欄位或協定物件。
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q242 Lockdown 如何限制指定 Command 或 Feature？
跟著解說理解
Lockdown 限制命令在選定介面與 controller 執行，用來控制管理入口；它不是加密資料或設定 namespace 唯讀。
1. 操作前先準備什麼
CSEL=0 選 subsystem，1 選指定 controller，2 選指定 primary 的 secondary 群組；IFC 另選收命令的介面。
查 OACS.CFLS／CCFLS 與 LID14h 的可禁止清單；哪些 Opcode／FID 可禁止由實作宣告。
- FID
- Feature Identifier，功能識別碼
CDW10.SCP 選 Admin Opcode 或 Set Features FID，OFI 指目標，PRHBT=1 禁止、0 允許；CDW14.CSS 選 controller，必要時 UIDX 選定義。
2. 先後順序與完成條件
先查能力與清單，再送 Lockdown，等成功後讀目前禁止清單，最後以相同介面驗證目標命令。
成功後選定目標受限制；重複禁止已禁止項目，或允許已允許項目，都不是錯誤。
3. 未符合條件時如何處理
不可禁止項目必須回命令特定 Prohibition of Command Execution Not Supported；不支援 CCFLS 卻指定非零 CSEL 須 Invalid Field。
一個 FID 被禁止是阻止 Set，不是同時禁止 Get；也不等於 Set Features 全部 Opcode 被禁止。
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q243 執行被 Lockdown 禁止的命令或 Feature 應如何回應？
跟著解說理解
成功設下禁止後，還要驗證目標操作真的被阻擋，不能只看到設定命令成功就結束。
1. 先區分是哪一種失敗
條件包含目標 controller、收到命令的介面、Opcode 或 Set FID，以及適用 UUID。
Admin SQ 上收到符合禁止條件的命令，必須中止並回 Command Prohibited by Command and Feature Lockdown，SCT=0、SC=23h。
- SQ
- Submission Queue，提交佇列
- SCT
- Status Code Type，完成狀態代碼類型
Lockdown 命令自己不被支援或參數非法，與已禁止的目標命令被拒絕，是不同 Status。Personality 的 CDP Authentication 明定例外也要保留。
2. 用哪些資料確認原因
讀目前禁止清單，並確認原 Lockdown 的 CQE 與所選範圍。
先成功建立禁止，再送一筆其餘參數合法的目標命令，最後查 CQE 及操作是否未執行。
3. 結果與後續驗證
驗證中的預期成功，是禁止生效而目標命令被拒絕；不是要求目標也回 Successful Completion。
LDPE 啟用且符合 authenticated unfreeze 支援條件時，指定 CDP Authentication 的 Security Send／Receive 必須允許，即使先前被禁止。
先檢查是否測到錯誤介面、錯誤 controller，或規範明定的允許例外。
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q244 Lockdown Log 的一般與增強格式如何解讀？
跟著解說理解
Log 分開回報「可以禁止」與「目前禁止」，這兩份清單不能互換。
1. 先確認資料的來源與範圍
一般格式的部分清單描述全體 controller；增強格式可指定單台或以 FFFFh 彙整至少一台回報的項目。
查 CFLS、CCFLS；ELPF=1 需要 controller-scoped 支援，LSI.CNTLID 只在增強格式使用。
2. 欄位、單位與判讀例子
LSP.CNTTS=0 可禁止、1 Admin 已禁止、2 帶外已禁止；SCP 選 Opcode／FID。一般 LNGTH 是 bytes 數；增強依 SZE、NCFID、CFIDS 解析 descriptors。
先確定查詢條件，再檢查 Header 回報的 CS／SS。增強 FFFFh 清單中 ACNTL=1 表示全體，0 表示至少一台但非全體。
例如兩台中只有 controller1 禁止 FID12h，增強彙整可列它且 ACNTL=0；不能因此說「沒有禁止」。
3. 判讀時要保留的條件
不支援 CCFLS 卻要求增強格式須 Invalid Field；不能把每份增強 Log 固定當成 512 bytes。
以特定 controller 查詢驗證彙整清單，再比較實際命令，避免把聯集誤看成交集。
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
Q245 Reset 與 Power Cycle 後 Lockdown 是否保留？
跟著解說理解
持續性取決於 CSEL 與 Lockdown Persistence，不能只用「Lockdown 已啟用」一個布林值判斷。
1. 先界定觸發方式與影響對象
先區分 subsystem 禁止與指定 controller／secondary 群組禁止。
保存原 Lockdown 的 CSEL、PRHBT、IFC 與目標，並讀 Personality 的實際 LDPS。
2. 哪些狀態改變，恢復後怎麼處理
LDPE 是設定輸入，LDPS 是回覆狀態；前者寫入不等於後者必然已成功生效。
重設前讀清單，執行指定種類的 Reset 或 Power Cycle，再以相同 selector 讀回並驗證目標命令。
一般 Reset 保留禁止；Power Cycle 後 CSEL0 依 LDPS 保留或解除，CSEL1／2 不取得跨斷電持續性。
3. 重設或斷電時，要確認什麼
| 觸發方式 | 這項操作或狀態會如何變化 |
|---|---|
| Controller Reset 後是否保留或繼續？ | 成功建立的禁止狀態不因一般 CLR 解除；要允許命令，需合法的後續 Lockdown 操作，或符合指定的 power-cycle 解除條件。 |
| NVM Subsystem Reset 後是否保留或繼續？ | Subsystem Reset 不等於 Power Cycle，不能用它自動解除禁止。仍要保留相同 scope 的狀態，並考慮 personality 明定的例外。 |
| Power Cycle 後是否保留或繼續？ | CSEL=0 的 subsystem 禁止，LDPE=1 時跨 Power Cycle 保留，直到後續操作解除；LDPE=0 則在 Power Cycle 解除。CSEL=1／2 的禁止到 Power Cycle 為止，不因 LDPE=1 就取得跨斷電持續性。 |
4. 如何驗證保留或恢復結果
不能因 Subsystem Reset 沒解除就當作失敗，也不能因 LDPE=1 就要求所有 controller-scoped 禁止跨斷電存在。
同時核對範圍、實際 personality 狀態與重設種類，才能得出唯一預期。
先檢查是否把 Controller Reset、Subsystem Reset 與真的斷電混稱為 Reset。
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
本題原文定位
來源：Base 2.4 §5.2.28–5.2.29 · Base 2.4 §5.2.16, 8.1.5 · Base 2.4 §5.2.13.1.20 · Base 2.4 §5.2.30.1.25.4–5.2.30.1.25.4.1 · Base 2.4 §5.2.14.2.1 · Base 2.4 §3.7.1–3.7.4 · Base 2.4 §4.2.3 · Base 2.4 §5.2.13.1.2 · Base 2.4 §5.2.2 · Base 2.4 §5.2.13.1.14 (header, reset, hardware, Set Feature events)
原文定位與既有圖表判讀
Base 的文件頁碼等於 PDF 頁碼減 26；NVM 與 PCIe 兩份規格的文件頁碼則與 PDF 頁碼相同。以下依提供的 PDF 本文列出章節、頁碼及 Figure 編號。若同一頁包含其他主題，只引用本題需要的定義，不納入 Fabrics 或 PCIe Link、封包內容。
- Base 2.4 · §3.7.1–3.7.4
文件頁 120–124 · PDF 146–150 - Base 2.4 · §4.2.3
文件頁 145–155 · PDF 171–181 · Figure 101–105 - Base 2.4 · §5.2.2
文件頁 183–190 · PDF 209–216 · Figure 150–156 - Base 2.4 · §5.2.13.1.2
文件頁 218–220 · PDF 244–246 · Figure 212 - Base 2.4 · §5.2.13.1.14 (header, reset, hardware, Set Feature events)
文件頁 244–256, 258, 262–264 · PDF 270–282, 284, 288–290 · Figure 232–244, 246, 252–253 - Base 2.4 · §5.2.13.1.20
文件頁 279–283 · PDF 305–309 · Figure 274–278 - Base 2.4 · §5.2.14.2.1
文件頁 340–387 · PDF 366–413 · Figure 338–341 - Base 2.4 · §5.2.16, 8.1.5
文件頁 405–408, 597–599 · PDF 431–434, 623–625 · Figure 365–367 - Base 2.4 · §5.2.28–5.2.29
文件頁 454–456 · PDF 480–482 · Figure 456–462 - Base 2.4 · §5.2.30.1.25.4–5.2.30.1.25.4.1
文件頁 493–494 · PDF 519–520 · Figure 518–519
需要看欄位圖時
以下連結可開啟對應的圖表教學，查閱欄位及判讀方式。每張圖保留固定的教學位置，方便之後反覆查詢。
- Base 2.4 Figure 101 · Completion Queue Entry: Status Field
- Base 2.4 Figure 104 · Status Code – Command Specific Status Values
- Base 2.4 Figure 338 · Identify – Identify Controller Data Structure, I/O Command Set Independent
使用的原始文件
- NVM Express Base Specification · Revision 2.4 · 2026-07-31
NVM-Express-Base-Specification-Revision-2.4-Ratified-2026.07.31.pdf - NVM Express NVM Command Set Specification · Revision 1.3 · 2026-07-31
NVM-Express-NVM-Command-Set-Specification-Revision-1.3-Ratified-2026.07.31.pdf - NVM Express NVMe over PCIe Transport Specification · Revision 1.4 · 2026-07-31
NVM-Express-NVMe-over-PCIe-Transport-Specification-Revision-1.4-Ratified-2026.07.31.pdf
Comments