Controller 初始化與停用

1. 先確認資料的來源與範圍

讀取 CAP 與 VS 只會取得目標 controller 的資訊，不會改變 queue 或媒體狀態。即使已確認 NVMe 版本，Host 仍須逐項檢查選配功能，因為版本相同不代表支援的功能完全相同。

VS 的 MJR、MNR、TER 欄位共同表示版本。Queue 與命令集能力則由 CAP 提供：MQES+1 是單一 I/O queue 的 entry 數量上限，CQR 說明是否要求實體記憶體連續，CSS 則說明支援哪些命令集選擇方式。

2. 欄位、單位與判讀例子

這些欄位使用不同的編碼方式。CAP.TO 以 500 ms 為單位；相鄰 Doorbell 的間距是 2^(2+DSTRD) bytes；可選的記憶體頁面大小則介於 2^(12+MPSMIN) 與 2^(12+MPSMAX) bytes。判斷啟用逾時時，還必須一併讀取 CRTO。

Host 先建立 NVMe Register 的位址映射，再讀取 VS 與 CAP。根據讀到的能力，選擇合法的 MPS、CSS、AMS 與 Ready Mode，接著配置 queue。若 IOCSS=1，則在啟用後以 Identify CNS 1Ch 查詢可使用的命令集組合。

CNS

Controller or Namespace Structure，選擇Identify回傳結構

讀取成功後，Host 應能算出合法的配置範圍；這次 Register 讀取本身不會產生 CQE。例如，MQES=03FFh 表示最多 1024 個 queue 位置，而 DSTRD=2 表示相鄰 Doorbell 相隔 16 bytes。

CQE

Completion Queue Entry，佇列中的完成項目

3. 判讀時要保留的條件

讀取唯讀 Register 不會以 Invalid Field CQE 回覆錯誤。至於後續設定，若 Host 把不支援的值寫入 CC.MPS 或 CC.AMS，規範可能將結果定義為 undefined behavior；此時不能要求 controller 回傳某個固定錯誤碼。

驗證時，應確認 CC.CSS 選用的命令集符合 CAP.CSS 宣告的能力及 Identify 回報的組合。同樣地，Create Queue 的 QSIZE 必須符合 MQES 限制。Admin Queue 則另受 AQA 的 4096 個位置上限約束，不能與 I/O queue 的上限混為一談。

1. 操作前先準備什麼

這些設定影響目標 controller 的管理介面。若 queue 位址填錯，controller 就可能無法讀取命令或寫入完成結果，導致後續 Identify、Get Features 等命令都無法正常完成。

先從 CAP 確認可用的 MPS 範圍、CSS、AMS 與 CRMS，再檢查 AQA 對 Admin Queue 長度的限制。Host 選用的配置必須同時符合這些條件。

AQA.ASQS 與 ACQS 儲存的是 entry 數量減 1；ASQ 與 ACQ 則提供實體起始位址，且必須依 CC.MPS 對齊。CC 還需設定 CSS、MPS、AMS 與 CRIME。若使用 NVM I/O，IOSQES 與 IOCQES 分別設為 6 與 4。

2. 先後順序與完成條件

先等待前一次重設完成，確認 RDY=0，再配置實體連續的 Admin Queue 記憶體，並把 Admin CQ 的 Phase 初始化為 0。接著，在 EN=0 時寫入 AQA、ASQ、ACQ 及合法的 CC 設定。將 EN 設為 1 後，等待 RDY=1。I/O entry 大小則必須在建立 I/O Queue 前設定完成。

CQ

Completion Queue，完成佇列

初始化成功後，Host 可以透過 Admin Queue 提交 Identify。不過，I/O Queue 仍需另外建立；若採 Independent mode，也不能只憑 RDY=1 就認定所有媒體都已就緒。

3. 未符合條件時如何處理

例如，以 AQA size=0 的配置啟用 controller、在 EN=1 時修改 MPS，或選用不支援的 MPS／AMS，都可能落入規範所稱的 undefined behavior。這些是 Register 使用方式的問題，不能擅自規定 controller 必須回傳 Invalid Field CQE。

驗證時，先確認 Register 的編碼正確，再確認 Admin CQ 能收到與原命令 CID 相符的 Identify 完成結果。CC.EN=1 只表示 Host 已要求啟用，單憑這個值還不足以證明初始化完成。

CID

Command Identifier，同一提交佇列內的命令識別碼

1. 操作前先準備什麼

這裡判斷的是目標 controller 的啟用狀態。至於媒體是否已可存取，還要配合所選的 Ready Mode，不能只看一個 RDY 值。

讀取 CAP.CRMS、CC.CRIME、CRTO.CRWMT／CRIMT 及 CAP.TO，確認目前採用哪種 Ready Mode 及等待期限。不能假設所有啟用情況都只需要查看 CAP.TO。

2. 先後順序與完成條件

3. 未符合條件時如何處理

透過 Register 啟用 controller，不會產生 CQE。若媒體尚未就緒，只有符合對應條件的命令，才能回報 Namespace Not Ready（SCT=0, SC=82h）或 Admin Command Media Not Ready（0/24h）。

SCT

Status Code Type，完成狀態代碼類型

應把啟用時間、CRIME、命令種類與回傳 Status 放在同一條時間軸上核對。Figure 84 只允許列出的 Admin 命令在特定條件下回報媒體尚未就緒，並非所有 Admin 命令都能用這個理由暫時拒絕執行。

4. 錯誤完成與紀錄要如何對照

透過 Register 啟用 controller，不會產生 CQE，因此這個動作本身沒有 DNR 或 More。Independent mode 在合法等待期間，若命令因媒體尚未就緒而失敗，可以回報 DNR=0；超過 CRWMT 後，就不得繼續以相同的暫時性理由回報 DNR=0。More 則依 Error Information Log 是否有該命令的補充資訊設定。

DNR

Do Not Retry，命令重試的狀態提示

若發生 §3.5.4.1 定義的初始化期限失敗，而且 controller 支援 PEL，必須記錄 NVM Subsystem Hardware Error Event，原因為 Controller Ready Timeout Exceeded。這是失敗條件觸發的紀錄，不是每次 Enable 成功都必須新增的事件。

1. 操作前先準備什麼

清除 EN 會觸發目標 controller 的重設，影響其所有 I/O Queue。因此，這個動作並不是只暫停其中一條 SQ。

SQ

Submission Queue，提交佇列

CAP.TO 說明清除 EN 後，Host 應等待 RDY 從 1 變成 0 的最長時間。驗證時，也應保存 CC、CSTS 的讀值及時間，才能確認轉移是否在期限內完成。

在正常停用流程中，Host 從 EN=1、RDY=1 的狀態清除 EN。清除後還必須等到 RDY=0，才能重新啟用 controller。

2. 先後順序與完成條件

Host 先停止提交新命令，再清除 EN，並持續讀取 RDY。等到 RDY=0 後，重新初始化 Admin CQ 與 Host 的命令追蹤資料，完成 CC 設定，最後才把 EN 設回 1。

RDY=0 才是停用完成的判斷依據，不需要等到每筆舊命令都收到獨立 CQE。此時原有的 I/O Queue 已失效，不能繼續使用。

3. 未符合條件時如何處理

若 RDY 還是 1，Host 就把 EN 從 0 設回 1，結果屬於 undefined behavior。由於這是 Register 操作，不是提交 Admin 命令，因此不能要求 controller 以 Command Sequence Error 回覆。

核對 EN、RDY 的轉移順序後，還應確認 Host 已停止使用舊 queue。即使舊記憶體裡仍看得到資料，也不代表該 queue 仍可繼續運作。

1. 何時可以提交命令

這個限制適用於該 PCIe controller 的 Admin 與 I/O 命令提交。初始化時先設定 Admin Queue Register 是建立通道的步驟，不能將它視為已經送出命令。

判斷能否提交時，必須同時確認 CSTS.RDY、CC.EN 及目標 queue 是否存在。即使 RDY=1，也仍需檢查 queue 是否已建立，以及 controller 是否處於 shutdown 狀態。

先等到 RDY=1，並確認目標 queue 已建立且尚未刪除。接著，讓 SQE 的內容對裝置可見，再更新 SQ Tail Doorbell，完成提交。

SQE

Submission Queue Entry，佇列中的命令項目

2. Doorbell 不能取代就緒條件

SQ Tail Doorbell 告訴 controller 哪些新命令已提交；CQ Head Doorbell 則告訴 controller，Host 已處理到哪個完成位置。這兩種通知都不能讓尚未就緒的 controller 提前進入 Ready 狀態。

若 Host 在 controller 或 queue 尚不可用時提交，不能期待收到固定的錯誤 CQE。原因是停用中的 Admin Queue 本來就無法作為可靠的錯誤回報通道。

如果看到 EN=1、RDY=0 且等待逾時，應先檢查初始化是否完成。此時尚未合法提交的 Identify 沒有回覆，不能據此判定裝置不支援 Identify。

1. 先保留哪些證據

嚴重的 controller 異常可能影響整個命令服務；某個 namespace 的媒體錯誤，則不一定具有相同的影響範圍。兩者需要分別判斷。

應一併觀察 CSTS.CFS、RDY、CC.EN 與適用的等待期限。Identify 中宣告支援某項選配功能，並不會讓 Host 可以忽略 CFS 所指出的狀態。

先保存 Register，以及已取得的 CQE 和 Log。若管理通道仍可使用，再讀取其他診斷資訊；若通道已無回應，就不能無限等待 Get Log Page 完成。

2. 依什麼順序排除原因

先確認 Register 讀取仍有效，以及 CFS 真的是 1；不可將失效讀取的全 1 值直接解碼成每個狀態位都成立。

Host 應根據故障情況，以及目前還能存取哪些控制介面，選擇適當的 Controller Level Reset。等狀態轉移完成後，再重新初始化。若控制介面完全沒有回應，則需要平台層的恢復處理；一次清除 CC.EN 並不保證能排除所有故障。

3. 把觀察結果接回規格條件

恢復後，還要確認 RDY 正常、Identify 可完成，而且新 queue 能正確處理命令。CFS 已清除只表示該狀態不再成立，不能單憑這點認定資料完整性也已通過驗證。

若 controller 還能回報受影響命令的結果，Internal Error（SCT=0, SC=06h）可能適用。若故障已嚴重到無法透過 CQE 溝通，則可能改由 CFS 指示異常；此時不能要求每筆命令都留下 CQE。

應對照同一時間的 CFS、初始化等待期限與硬體錯誤紀錄，確認它們是否指向相同事件。單筆命令回傳 Invalid Field，並不足以證明 controller 已進入 Fatal 狀態。

1. 機制與適用範圍

這裡討論兩種模式：Controller Ready With Media，以及 Controller Ready Independent of Media。它們規定的是介面與媒體的就緒關係，而不是額外定義一組可任意解讀的 degraded-ready 狀態碼。

CRIME=0 選擇 With Media，CRIME=1 選擇 Independent。判斷當下允許執行哪些命令時，要一起檢查 CSTS.RDY、CRTO.CRIMT／CRWMT，以及 Figure 84 的命令分類。

2. 用操作與結果理解

CAP.CRMS 中的 CRWMS、CRIMS 分別宣告兩種模式的支援能力。當 CAP.CRMS=11b 時，Host 可以透過 CC.CRIME 選擇要使用的模式。

Host 必須在啟用前選好模式。若選擇 Independent 模式，RDY=1 後可先執行不依賴媒體的查詢；需要媒體的命令若收到允許的暫時性 Status，則延後處理。同時仍要追蹤從 Enable 開始計算的 CRWMT，不能重新起算。

With Media 模式正常就緒時，controller 應已能處理所要求的媒體存取。Independent 模式的 RDY=1 則先表示介面及適用命令已可服務，尚不能據此認定所有 namespace 都已就緒。

3. 容易誤判的地方

在規範允許的條件下，controller 可以回傳 0/82h 或 0/24h；其中 0/24h 只適用於 Independent 模式下特定的 Admin 命令。超過媒體就緒期限後，若仍以同一個暫時等待理由回報 DNR=0，就不符合該期限的要求。

同時核對 CAP 宣告、CC 選擇、timeout 與命令行為。CSTS.PP 是另一種暫停處理指示，不是第三個 Ready Mode。

1. 差別在哪裡

啟用或清除 CC.EN 的作用對象是單一 controller。NVM Subsystem Reset 則依規範涵蓋相應的 subsystem 或 domain 範圍；Shutdown 也另有 controller 與 subsystem 層級，必須先確認使用的是哪一種。

Enable：EN 0→1。Controller Reset：EN 1→0。NSSR.NSSRC 寫 4E564D65h 觸發支援的 subsystem reset。正常 controller shutdown 用 CC.SHN=01b，觀察 CSTS.SHST=10b。

2. 如何選擇與確認

CAP.NSSRS 可用來確認是否支援 NSSR。判斷 Shutdown 的作用範圍時，則還要查看 CAP 宣告的 shutdown 能力與 CSTS.ST。

若準備正常移除電源，Host 應先協調 I/O，再送出 Shutdown 通知，並等待關機處理完成。若目的是故障恢復，則選擇合適的 Reset，之後重新建立命令處理環境。

不同動作有不同的完成判斷：啟用時等待 RDY=1；停用或重設時檢查對應的狀態轉移；Shutdown 則等待 SHST=10b。Shutdown 完成不表示所有 Register 都已回到重設值。

3. 比較時要保留的條件

Register 操作本身沒有 CQE。Shutdown 過程中，controller 可以對適用命令回報 Commands Aborted due to Power Loss Notification（0/05h）；但不能因此把所有 Reset 中未完成的命令，都預期為相同 Status。

應先記錄觸發方式與影響範圍，再比較操作前後保留了哪些值。如果紀錄只寫「reset」，就無法說明 AQA、PCIe 狀態與 Feature 為何有不同的保留結果。

1. 先界定觸發方式與影響對象

本題只討論清除 CC.EN 所觸發的 Controller Reset。FLR 與 NVM Subsystem Reset 來自不同觸發方式，不能直接套用這裡的 Register 保留規則。

FLR

Function Level Reset，以功能為範圍的重設

先查看 §3.7.2 的重設例外，以及各 Register 的 Reset 欄，確認哪些值會保留。Feature 則還要考慮作用範圍、是否可保存設定，以及 Figure 126、127、466 的恢復規則。

2. 哪些狀態改變，恢復後怎麼處理

這種重設會保留 AQA、ASQ、ACQ、指定的 PMR Register 與 CMBMSC，但仍會重設 Admin Queue 的指標，並刪除所有 I/O SQ／CQ。Host 因此需要重新配置 CC。Feature 的恢復方式則另行判斷：可保存設定者依重設範圍恢復 Saved，沒有 Saved 時使用 Default；不可保存設定者依持續性規則處理。HMB 也需要重新配置。

PMR

Persistent Memory Region，持久性記憶體區域

HMB

Host Memory Buffer，主機記憶體緩衝

先等到 RDY=0，確認保留的 Admin Queue 記憶體仍可使用，並把 Admin CQ 的 Phase 初始化為 0。完成配置並啟用後，重新查詢必要的能力與 Feature，再協商 Number of Queues，最後依序建立 CQ 與 SQ。

重建成功後，新命令應能在新建立的 queue 上正常完成。即使沿用相同的 QID 或記憶體位址，也不表示上一輪 queue 可以接續使用。

3. 如何驗證保留或恢復結果

重設中斷的舊命令沒有統一、必須回傳的「Reset Status」。重建時若使用非法 QID 或大小，則依對應 Create 命令的規則判斷。直接對舊 queue 更新 Doorbell，不能代替重建流程。

應比較重設前後的 Register、Get Features 回覆與實際可用的 Queue 配置。尤其要分清楚：AQA 的值被保留，不代表 Admin CQ 裡的舊內容仍然有效。

先確認 Host 已清除上一輪未完成命令的對照資料，並重新初始化 Phase。即使新命令重用了相同 CID，也不能把它對應到上一輪的命令。