1. 操作前先準備什麼

每個 controller 有 QID=0 的 Admin SQ／CQ；這不是一般 I/O QID。

AQA 指定 Admin SQ 與 CQ 各自的長度，ASQ 與 ACQ 則提供各自的實體起始位址。這兩條 queue 必須使用實體連續的記憶體，不能套用 Create I/O Queue 中 PC=0 的 PRP list 建立方式。

PRP

Physical Region Page，描述資料頁位置的指標

ASQS、ACQS 均為 zero-based；64 entries 寫 63。Admin SQE 64 bytes、CQE 16 bytes；兩條 queue 可以有不同長度。

SQE

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

CQE

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

2. 先後順序與完成條件

Host 先配置並初始化記憶體，再於 EN=0 時寫入 AQA、ASQ、ACQ，並把 Admin CQ 的 Phase 初始化為 0。完成 CC 設定後啟用 controller，等到 RDY=1，才提交第一筆 Admin 命令。

Host 應能透過 Admin SQ 提交 Identify，並在 Admin CQ 收到 CID 相符的完成結果。ACQ 與 interrupt vector 0 關聯，但 Host 也可以輪詢 Phase 來辨認完成，不一定要等待中斷通知。

CID

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

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

size=0 編碼的是一個位置，不是停用 queue 的合法方式；以這種配置啟用 controller，結果屬於 undefined behavior。此外，Delete I/O Queue 只用來刪除 I/O Queue，不能用來刪除 Admin Queue。

應同時核對 AQA 的長度、實際配置的記憶體與第一筆 CQE。即使 Register 回讀值正確，也還不能證明 controller 真的能存取 Host 提供的記憶體。

CQE

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

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

對齊與大小規則會因 queue 類型及記憶體位置而異。Admin Queue、一般 I/O Queue，以及能力允許時放在 CMB 的 queue，必須分別確認，不能把其中一種配置的規則直接套到其他配置。

CMB

Controller Memory Buffer，控制器記憶體緩衝

Admin Queue 的長度限制來自 AQA；I/O Queue 則要核對 CAP.MQES、CQR 與 CC.IOSQES／IOCQES。如果使用 CMB，還須確認 CMBSZ 的 queue 支援能力，以及 CMBLOC.CQDA／CQPDS 定義的例外。

CMB

Controller Memory Buffer，控制器記憶體緩衝

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

Queue 長度欄位編碼的是 entry 數量減 1。在一般配置中，queue 的基底位址，以及非連續 queue 的各個 PRP 頁面，都要依 CC.MPS 對齊，PRP1 的 offset 則為 0。

PRP

Physical Region Page，描述資料頁位置的指標

先決定 queue 有幾個位置、每筆 entry 有多大，再算出所需 bytes 數並配置頁面。如果支援非連續配置，接著建立 PRP list，最後提交 Create 命令。Queue 仍有效時，Host 不得任意修改這份 PRP list。

每條 queue 至少需要 2 個位置。Admin Queue 最多有 4096 個位置，I/O Queue 則最多有 min(65536, MQES+1) 個。為了分辨 Full 與 Empty，環狀 queue 還必須保留一個位置不使用。

3. 判讀時要保留的條件

I/O queue 的 QSIZE 為 0 或超過支援範圍時，規格建議回報 Invalid Queue Size（1/02h）；PRP offset 非零時，建議回報 PRP Offset Invalid（0/13h）。若 PC 設定違反 CQR 要求，則要分別確認 Create SQ 與 Create CQ 使用的是建議還是強制回覆，不能把兩者的要求強度視為相同。

例如，同樣有 128 個位置，NVM SQ 需要 8192 bytes，而 CQ 只需要 2048 bytes。兩者的 QSIZE 雖然都是 127，每筆 entry 的大小卻不同，因此不能只憑 QSIZE 相同，就把所需的記憶體容量算成同一個數值。

1. 操作前先準備什麼

一個 SQ 在建立時指定其 CQ；多個 SQ 可以指向同一個已存在的 CQ。

Base 2.4 的初始化流程建議使用 Set Features 的 Number of Queues 確認配額；實際建立時，也要確認 CAP.MQES／CQR、entry 大小及可用的 interrupt vector。Create 命令必須符合適用的欄位限制。這裡將規格建議的初始化順序與 Create 欄位的要求分開看。

Create CQ 用 PRP1、QID、QSIZE、PC、IEN、IV；Create SQ 加上 CQID、QPRIO、NVMSETID。NVMSETID=0 表示沒有指定 Set 關聯。

2. 先後順序與完成條件

SCT

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

SQE

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

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

CQID 在支援範圍內但未建立，回 Completion Queue Invalid（1/00h）；CQID=0 或超界回 Invalid Queue Identifier（1/01h）。

應確認 Create SQ 的 CQID 與 Host 保存的 SQ→CQ 對照一致。Create CQ 成功只代表該 CQ 已存在，並不會自動把所有 SQ 都連到它。

1. 差別在哪裡

多條 SQ 共用的是 CQ 的完成位置及相關通知資源。各條 SQ 仍各自管理 CID，所以不會因此變成共用同一個命令識別空間。

CID

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

Host 以 CQE 的 SQID 與 CID 找到原命令，再以 SQHD 更新該 SQ 已被 controller 消費到的位置。

SQID

Submission Queue Identifier，提交佇列識別碼

2. 如何選擇與確認

Number of Queues 分別回傳 SQ 與 CQ 的配額；Create SQ 的 CQID 指出它使用哪條 CQ；Create CQ 的 IEN 與 IV 則設定中斷通知。這三組欄位分別處理數量、關聯及通知。

先建立 CQ，再建立多條 SQ，並讓它們的 CQID 指向同一個 CQ。Host 讀取 CQE 時，先以 SQID 找出來源 SQ，再處理該命令的完成；處理完畢後，更新共用 CQ 的 Head。

SQID

Submission Queue Identifier，提交佇列識別碼

例如，SQ1/CID7 與 SQ2/CID7 可以同時存在，Host 必須把回覆各自對回正確的 SQ。這不代表同一條 SQ 也可以在命令尚未完成時，重複使用同一個 CID。

3. 比較時要保留的條件

合法地共用 CQ 不會造成錯誤。若 Create SQ 指定不存在的 CQID，則使用該命令定義的錯誤 Status。至於共用 CQ 已滿，應按空間不足的處理規則判斷，不能把它當成每條 SQ 都要回報 Invalid Queue Size。

應一起觀察 CQ 可用的位置數、各 SQ 的完成流量，以及 Host 處理完成的速度。只知道建立了多少條 SQ，還不足以判斷共用 CQ 是否成為瓶頸。

1. 要查哪個對象、哪份資料

Admin Queue 一律要求實體記憶體連續。I/O Queue 能否使用實體不連續的頁面，則取決於 CAP.CQR，以及 queue 配置在哪一種記憶體中。

CQR=1 要求實體連續；CQR=0 允許 I/O 使用非連續頁面。放在 CMB 時還要查 CMBSZ.SQS／CQS、CMBLOC.CQPDS／CQDA。

PC 決定 PRP1 的解讀方式：PC=1 時，PRP1 直接指向 queue 的基底位址；PC=0 時，PRP1 指向描述各個 queue 頁面的 PRP list。這裡不能套用一般資料傳輸中 PRP2 的判斷方式。

2. 查詢順序與回覆判讀

Host 先確認記憶體位置與支援能力，再建立完整且符合對齊要求的頁面清單，最後提交 Create。Queue 仍在使用期間，清單的位置與內容都必須保留，直到 Delete 成功或重設終止該 queue 為止。

建立成功後，controller 應能按照所選的記憶體形式讀取 SQE 或寫入 CQE。不過，Create 成功並不表示 Host 可以在 queue 使用中重新排列頁面。

3. 證據不足或不一致時怎麼判斷

CQR=1 且 PC=0：Create CQ 必須（shall）回 Invalid Field（0/02h），Create SQ 的對應要求為建議（should）回覆；不支援的 CMB 用法可能為 Invalid Use of Controller Memory Buffer（0/12h）。

驗證時，要把 CAP.CQR、Create 命令的 PC、PRP1 指向的內容，以及實際頁面配置一起核對。只確認 Create 回報成功，還不足以證明 Host 對這些欄位的解讀正確。

先確認 PRP1 應該指向 queue 本體，還是 PRP list。如果把兩者弄反，即使位址可存取，controller 讀到的內容仍不是它預期的資料結構。

1. 先區分是哪一種失敗

這裡檢查的是透過 Admin Queue 提交的 Create I/O Queue 命令。判斷 QID 是否重複時，SQ 與 CQ 各有自己的識別空間，必須在相同類型內比較。

重點檢查 QID、CQID、QSIZE 與 IV，這些參數位於 CDW10／11。同時確認 IOSQES 與 IOCQES 已正確初始化，避免將 entry 大小設定錯誤誤認為個別 queue 參數的問題。

同類 QID 重複／0／超範圍，規格建議回 1/01h；QSIZE=0 或超支援，建議回 1/02h。Create SQ 的 CQID 若在合法範圍內但尚未建立，必須回 1/00h；CQID=0 或超界則必須回 1/01h。IV 超過 Transport 1.4 Figure 7 所述範圍時，建議回 1/08h。多個錯誤同時成立時，除特別規定外由實作選擇回哪個。

2. 用哪些資料確認原因

CAP.MQES、Number of Queues 回覆和 PCIe interrupt 配置是合法範圍的依據。

先建立一組合法的參數作為比較基準，再一次只改一個條件，例如重複的 QID 或未建立的 CQID。若一筆命令同時有多個錯誤，controller 可能先回報其中另一個錯誤，讓測試結果難以判讀。

3. 結果與後續驗證

合法參數回成功並建立指定 queue；失敗後不能把該 QID 當成已建立。

若 Error Information Log 有對應紀錄，可用 Parameter Error Location 找出錯誤欄位。但在沒有 More=1 的保證時，不能只因命令失敗，就要求一定新增一筆 Error Information entry。

先確認測例確實只有一個非法條件，再核對預期的 SCT。這類命令專用錯誤通常要以 SCT=1 搭配 SC 判讀，不能只比較 SC 數字。

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

FID 07h 作用於 controller，不包含 Admin SQ／CQ。

FID

Feature Identifier，功能識別碼

實際分配數量可從 Set Features FID 07h 的成功回覆 CQE DW0 取得；成功的 Get Features 若 SEL 不是 011b，也會在 DW0 回報分配數量。SEL=011b 查的是 Supported Capabilities，不能當成 queue 配額。CAP.MQES 則回答另一個問題：每條 I/O Queue 最多可以有幾個 entry。

FID

Feature Identifier，功能識別碼

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

CDW11 的 NSQR／NCQR 與 DW0 的 NSQA／NCQA 都是 zero-based；回覆可能比要求少，也可能因配置單位而較多。

Host 若要設定 Number of Queues，規格建議在初始化期間、建立任何 I/O Queue 之前送出。Controller Level Reset（CLR）後第一筆成功的 Set 會配置這一輪的 queue 數量；直到下一次 CLR 發生前，分配數量都不再改變。

例如，DW0=00030007h 表示分配了 4 個 CQ 與 8 個 SQ 的配額。Host 仍須逐一送出 Create 才能建立它們，而 CQ、SQ 的合法 QID 範圍分別依各自配額判斷。

3. 重設或斷電時，要確認什麼

4. 判讀時要保留的條件

若已建立 I/O Queue 才送出 Set，controller 必須回傳 Command Sequence Error（0/0Ch）。若要求值為 FFFFh，則建議回傳 Invalid Field（0/02h）。在尚未建立 queue 的情況下，再次送出 Set 應可成功，但不改變第一筆成功 Set 所決定的配額。

應分別保存回覆的配額、目前已建立的 queue 清單，以及 MQES 限制。Get Features 回報的是配額，不能將它解讀成目前實際存在的 queue 數量。

1. 操作前先準備什麼

一個 CQ 可能同時被多條 SQ 使用，因此要先刪除所有指向它的 SQ。只刪除與 CQ 具有相同 QID 的 SQ，並不足以滿足這個條件。

使用 Host 在 Create SQ 時保存的 SQ→CQID 對照；Number of Queues 不提供這張連線清單。

Delete I/O SQ／CQ 的 CDW10.QID 指定對象；它們都透過 Admin SQ 提交。

2. 先後順序與完成條件

Host 先停止向目標 SQ 提交新命令，並適當等待既有命令處理完畢。接著逐一送出 Delete SQ 並等待成功，處理仍需讀取的舊完成結果，最後才送出 Delete CQ。

Delete SQ 成功，表示該 SQ 的命令處理已到達規範定義的終止點。Delete CQ 成功後，Host 才能收回該 CQ 的 PRP list 與 queue 資源；兩個完成點不能互相代替。

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

尚有相關 SQ 時 Delete CQ 必須回 Invalid Queue Deletion（1/0Ch）；QID=0 或非法對象回 Invalid Queue Identifier（1/01h）。

應比較 Delete 成功回覆與記憶體釋放的先後時間。只要刪除命令尚未成功，Host 就不能僅憑「已送出 Delete」而提前回收裝置可能仍會存取的記憶體。

1. 先區分是哪一種失敗

刪除 SQ 會影響該 SQ 中尚未完成的 I/O。刪除 CQ 則另有前提：所有依賴它的 SQ 都必須已被刪除，才能繼續進行。

Delete 的 QID 必須有效且不為 0；目標 I/O 命令仍以各自 SQID／CID 辨識。

QID 非法時回報 1/01h；CQ 仍被 SQ 使用時回報 1/0Ch。原 I/O 命令若因刪除 SQ 而中止，可以透過 CQE 回報 Command Aborted due to SQ Deletion（0/08h），也可能在 Delete 成功時依規則形成隱含完成，沒有各自的 CQE。

2. 用哪些資料確認原因

先檢查 Host 記錄的 queue 建立與刪除結果，以及尚未完成的命令。這些是目前的執行狀態，不能只靠 Identify 的選配能力位得知。

正常拆除時，Host 先等待既有工作完成，再刪除 queue。若為了中止工作而直接刪除 SQ，Delete 成功時，先前提交且 controller 尚未張貼 CQE 的命令依規格形成隱含中止；已張貼但 Host 尚未讀取的 CQE，仍屬明確完成，不能只因 Host 還沒看到就當作隱含中止。

3. 結果與後續驗證

在 Delete SQ 成功之前，原命令可能正常完成，也可能收到表示中止的 CQE。但是 Delete SQ 一旦成功，controller 就不得再為那些原 SQ 命令寫入新的 completion。

驗證時，應區分 controller 在 Delete 成功前已張貼 CQE 的命令，與未張貼 CQE、因 Delete 成功而隱含中止的命令。若只有 Host 讀取紀錄，還要確認是否有已張貼但尚未讀取的 CQE；不能只用「尚未讀到」判斷。

先檢查 Delete SQ 是否已成功完成；在它還 outstanding 時，不能宣布所有原命令已停止。

1. 機制與適用範圍

刪除 SQ 不會一併刪除它使用的 CQ。如果 CQ 仍存在，其中先前已寫入的完成結果，仍可能等待 Host 處理。

Host 需要追蹤被刪除的 QID、關聯 CQID、PRP list 位址，以及記憶體何時可回收。即使同一位址稍後用來建立新 queue，也必須能分辨它屬於哪一輪配置。

2. 用操作與結果理解

以 Admin CQ 回報 Delete 成功的時點，判斷 queue 的刪除是否完成。Host 送出 Delete 的時間，或自行設定的 timeout 到期，都不能代替這個完成結果。

先停止提交新命令，再送出 Delete 並等待成功，之後才回收對應的 queue 記憶體與 PRP list。若只刪除 SQ，而 CQ 仍存在，Host 還須處理其中先前已寫入的完成結果。

Delete SQ 成功後，controller 不得再為原 SQ 的命令新增 completion。Delete CQ 成功後，Host 可釋放其 PRP list 與記憶體，controller 也不能再把已刪除的 queue 當作可存取的 DMA 目標。

DMA

Direct Memory Access，裝置直接存取記憶體

3. 容易誤判的地方

若 Delete 本身失敗或沒有完成，不能推論記憶體已可收回。逾時不是另一種 Successful Completion。

應一併核對 CQE 的寫入時間、Phase、Delete 完成時間，以及 Host 實際讀取 CQE 的時間。Host 較晚處理到舊 CQE，並不等於 controller 在刪除成功後才違規寫入。

1. 操作前先準備什麼

影響範圍包括目標 queue，以及重建時必須一併處理的相關 queue。例如，若要重建 CQ，就要先刪除所有使用它的 SQ；等 CQ 重建完成後，再重建這些 SQ。

依既有 SQ 與 CQ 的關聯，以及 Create／Delete 的順序規則執行。這個流程不依靠另一個獨立的 Queue Reset Feature。

流程會使用 Delete SQ／CQ 與 Create CQ／SQ。雖然 QID 可以重用，但新 queue 的記憶體與指標都屬於新一輪配置，不能接續上一輪的命令狀態。

2. 先後順序與完成條件

正常情況下，Host 先讓既有工作完成，再刪除 queue。若必須中止工作，則依 Delete SQ 的明確或隱含完成規則處理。重建時先初始化新 CQ 的 Phase，建立 CQ，最後才建立依賴它的 SQ。

重建成功後新命令可執行，原 outstanding 命令不會自動搬入新 SQ。

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

若 CQ 仍被 SQ 使用就嘗試刪除，會遇到 1/0Ch；若沒有有效 CQ 就建立 SQ，則依 CQID 的錯誤條件回覆。Queue Level Reset 是由這些命令組成的流程，本身沒有額外、統一的 Status。

核對刪除／建立順序與新舊 CID 對照，並檢查其他獨立 queue 是否保持正常。

1. 操作前先準備什麼

Controller Level Reset 刪除該 controller 的全部 I/O SQ／CQ；不同於只刪除一條 SQ。

恢復後應重新查詢必要的 Identify 資訊，並確認 Number of Queues 配額、entry 大小與中斷設定。不能未經確認，就假設上一輪設定仍可直接使用。

重建流程需要先設定 Admin Queue Register 與 CC，再視需要使用 Get／Set Features，最後以 Create CQ／SQ 建立 I/O 通道。這些步驟共同構成恢復流程，不能只做其中一部分。

2. 先後順序與完成條件

例如，Host 確認 RDY=0、初始化 Admin CQ 的 Phase 與 CC，啟用 controller 並等待就緒，再恢復必要的 Feature。Base 2.4 建議在初始化時用 Set Features 確認 Number of Queues；此例採用這個流程，依回覆建立 CQ、再建立 SQ。新 I/O 要等對應 queue 建立成功後才能提交。

每筆 Create 都必須先在 Admin CQ 成功完成，對應的新 queue 才能使用。即使沿用相同 QID 或位址，也不能跳過這個完成確認。

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

直接更新舊 queue 的 Doorbell，不是合法的恢復流程，不能要求 controller 繼續處理該 queue。若是在重新建立 queue 時命令失敗，則依對應 Create 命令的 Status 處理。

Host 應保存重設前後的 queue 建立紀錄與命令對照，用來區分新舊配置。這是 Host 自行管理的追蹤資訊，不是要求在 NVMe 傳輸格式中新增欄位。