Interrupt 設定與完成通知

1. 操作前先準備什麼

關聯建立在 I/O CQ 上，SQ 透過 CQID 間接使用該通知路徑。

SQ

Submission Queue，提交佇列

CQID

Completion Queue Identifier，完成佇列識別碼

先確認 PCIe 中斷模式及已配置的 vector 數，再建立 CQ。

Create CQ.CDW11 的 IV[31:16] 選 vector，IEN[1] 啟用該 CQ 中斷；PC[0] 控制記憶體配置。

2. 先後順序與完成條件

配置中斷資源、建立 CQ、建立關聯 SQ，之後才送 I/O 驗證通知。

SQ

Submission Queue，提交佇列

例如 CQ5 使用 IV2；來自 SQ7 的完成寫入 CQ5，Host 收 IV2 後查 CQ5，再由 CQE.SQID／CID 找命令。

SQID

Submission Queue Identifier，提交佇列識別碼

CID

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

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

Create CQ 指定不合法 vector 時對應 Invalid Interrupt Vector（SCT1、SC08h）；不能以 QID 是否有效代替 IV 檢查。

核對 CQ 建立成功、IV、IEN 與 Host 處理程序的 CQ 清單。

1. 差別在哪裡

合併門檻以 vector 為單位，同 vector 的多條 CQ 可能共同參與通知判斷。

CQE 仍以 SQID、CID 識別命令，中斷訊息不攜帶每筆命令的完整身分。

SQID

Submission Queue Identifier，提交佇列識別碼

CID

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

2. 如何選擇與確認

查目前模式的 vector 能力與已建立 CQ 的 IV／IEN。

建立 vector→CQ 清單，收到通知後檢查相關 CQ，處理有效 Phase 的 entries，再更新各自 Head Doorbell。

兩條 CQ 共用 IV3 時，一次中斷可引導 Host 處理兩邊多筆完成；不能期待每條 CQ 各一個通知。

3. 比較時要保留的條件

沒有一個通用「中斷數必須等於 CQE 數」規則；共用加上合併會讓兩者自然不同。

比較延遲與公平性時，分別統計每條 CQ 的寫入及 Host 處理時間，避免只看共用 vector 次數。

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

FID08h 僅適用 I/O queues，不適用 Admin CQ。THR 的門檻以 vector 為單位；TIME 則可由 controller 實作為個別 vector 計時，或跨所有 vectors 套用。

用 Get／Set FID08h 取得或設定 TIME 與 THR；Get 的 SEL=011b 回覆的是 Supported Capabilities，不是這兩個值。再查各 vector 的 FID09h.CD。

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

先讀 Base 2.4 Figure 543：TIME[15:8] 的單位是 100 µs；THR[7:0] 是 zero-based 的建議最小完成數。再讀 PCIe Transport 1.4 §3.5，確認這兩個值對實作的約束。

先確保兩欄非零且 CD=0，再以固定 workload 比較通知與 CQE 時間。

【模擬資料】TIME=5、THR=7 分別表示 500 µs 與每個 vector 8 筆 CQE 的建議值。假設兩條 CQ 共用同一 vector，且分別出現 3 筆與 5 筆完成，分析門檻時需一起看該 vector 的完成情況；通知不保證恰好在第 8 筆或 500 µs 發生。另一個 vector 的 TIME 如何計算，則需確認 controller 採每個 vector 計時，還是跨所有 vectors 套用。

3. 判讀時要保留的條件

PCIe Transport 1.4 要求 PCIe controller 支援相關 Get／Set Features 命令，但允許自行選擇合併算法，甚至不實作合併；不能因通知早於或晚於建議值，就單獨判定違規。

Host 更新 CQ Head 可讓計時或門檻重新開始；持續處理某 vector 的 workload 可能持續延後新通知。

1. 操作前先準備什麼

FID08h 影響 controller 的 I/O 中斷設定；FID09h.CD 可只停用指定 vector 的合併。

讀 FID08h、FID09h 及 CQ.IEN，確認目前設定與通知路徑。

TIME=0 或 THR=0 任一成立就隱含停用合併；CD=1 則禁止對該 vector 套用合併設定。

2. 先後順序與完成條件

需要全部停用時設定 FID08h；只停一條 vector 時，先有關聯 I/O CQ，再設定 FID09h。

設定後 Get 讀回正確；有可通知的完成時，依模式與 mask 判斷中斷，而非仍等待原聚合門檻。

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

即使 THR=0 的一般數量編碼看似 1，這裡仍有明確的停用規則，不能忽略。

關閉合併不保證每筆 CQE 都對應一次獨立中斷；共用 vector 與 Host 處理中的行為仍存在。

1. 操作前先準備什麼

Mask 阻止中斷送出，影響所有使用該 vector 的 CQ 通知。

先確認目前是 pin-based、MSI 還是 MSI-X，才能選正確的 mask 介面。

Pin／MSI 用 INTMS 寫 1 設 mask、INTMC 寫 1 清 mask；MSI-X 用 Function Mask 與 Table 的 Vector Mask。

2. 先後順序與完成條件

先保留原設定，再遮蔽、處理 CQ、更新 Head，最後解除遮蔽並檢查是否仍有待處理完成。

INTMC 對目標 bit 寫 1 才解除，寫 0 沒有作用；這和一般「寫 0 就是清除」的 Register 不同。

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

MSI-X 模式下 Host 不得存取 INTMS／INTMC，若違反，其結果未定義，不能編造必定的 NVMe Status。

Get FID09h.CD 只能證明合併設定，不能證明 MSI-X table 已解除 mask。

4. CQE、DNR 與 More 在這裡是否適用

DNR

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

Mask Register 讀寫沒有 NVMe CQE，DNR／More 不適用；如果同時用 Get／Set FID09h 查合併，只有那些命令才有 CQE。

DNR

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

1. 遮蔽的是通知，CQ 仍會前進

所有使用該 vector 的 CQ 都可能繼續累積完成，直到各自空間不足。

Controller 仍依正常規則寫 CQE；MSI-X 因 mask 不能送出的中斷會以對應 pending bit 表示。

看見新 Phase 的 CQE 卻沒有通知，在 mask 尚未解除時可能完全正常。

2. 如何觀察完成並避免 CQ 滿

讀實際 mask、CQ.IEN、CQ 位置與 Phase；MSI-X 可另看 PBA。

遮蔽後可用合法的 CQ 輪詢確認完成，處理後仍需更新 Head Doorbell 釋放空間。

CQ Full 是空間問題，與 mask 不同；長期不處理完成會間接讓 CQ 滿，但不是 mask 直接禁止寫入。

1. 操作前先準備什麼

共享 vector 時，要處理所有關聯且可能有新完成的 CQ。

核對 MSI-X 的 Function／Vector Mask、PBA，或 pin／MSI 的 INTM 及對應 CQ。

MSI-X 兩層 mask 都清除後，待送中斷才可送出；只清其中一層仍可能不通知。

2. 先後順序與完成條件

解除遮蔽後讀 CQ、依 Phase 處理，再更新各 Head；處理與重新掛通知間要避免漏掉剛到的新 CQE。

累積 10 筆完成可能由一次通知引導 Host 全部處理，不要求補送 10 次歷史中斷。

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

INTM 遮蔽 MSI 時，對應 MSI Capability pending 不會因此設起；不能把 MSI-X PBA 規則原封套用。

以「所有有效 CQE 是否被處理」判斷完整性，不以通知次數等於命令數判斷。

1. 操作前先準備什麼

FID09h 改指定 vector 的合併設定，會影響目前共用該 vector 的所有 CQ。

設定 FID09h 前，該 IV 必須已關聯一條存在的 I/O CQ。

CD=1 停用合併，CD=0 使用全域合併；它沒有修改 Create CQ.IV 的功能。

2. 先後順序與完成條件

保留 CQ 關聯，Set FID09h 後 Get 相同 IV；若需要換 CQ 的 IV，依合法 queue 生命週期重建該關聯。

已存在 CQ 正是設定 FID09h 的前提，不是禁止修改的理由。

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

IV 非法或未關聯存在的 I/O CQ 時，controller 應回 Invalid Field；這裡的 should 不等於強制唯一結果。

比較前後結果時，保存其他共用 CQ 與 mask 狀態，避免把外部條件變更誤算成 Feature 行為。

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

只重設一個 controller 與更大範圍 reset 不同，不能重配未受影響的另一台 controller。

先查 CC／CSTS 與 PCIe interrupt mode，再讀需要的 Feature Current。

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

FID08h 的 TIME／THR reset 值 0；FID09h 預設允許合併，但當全域合併停用時，不會因此自動啟用延遲。

恢復 Admin 通道、配置 vectors、重建 CQ／SQ，再設定 FID09h 與需要的 FID08h。

新的合法 CQE 可以經正確 vector 被 Host 找到，舊 CQE 不應混進新 queue 的完成追蹤。

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

FID09h 在 CQ 尚未重建前就設定，可能觸發未關聯 IV 的錯誤。

模式切換也可能失去合併設定，需重新設定；不能只測 CC.EN reset 就推論 Power Cycle。

先核對 reset 類型及新 CQ 建立成功的時點。

1. 操作前先準備什麼

同一 vector 可能仍被其他 CQ 使用，因此要按關聯計數回收。

保存 SQ→CQ→IV 關係與尚未完成命令，不能只列 SQ 編號。

先刪依賴的 SQ 並等待完成，再刪 CQ；成功後解除 Host 對該 CQ 的處理資料。

2. 先後順序與完成條件

最後檢查同 IV 是否還有其他 CQ，才決定移除 handler 或釋放 Host 中斷資源。

CQ1、CQ2 共用 IV3，刪 CQ1 後 IV3 仍需服務 CQ2；不應把 CQ2 的通知一起關掉。

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

CQ 仍被 SQ 引用時不能合法刪除；成功刪除前也不能提前回收 CQ 記憶體。

同時比對 queue 刪除 CQE、Host 關聯清單與剩餘 CQ 通知，避免資源洩漏或過早釋放。

1. 先保留哪些證據

追蹤一條完整路徑：SQ 的命令、關聯 CQ、使用的 vector 與 Host 處理程序。

讀 CQ.IEN／IV、FID08h、FID09h、真實 mask 與 CQ Phase。

保存提交時間、CQE 出現時間、通知時間與 Head 更新時間，四者不是同一時點。

2. 依什麼順序排除原因

先從該命令的 CQ 位置與 Phase 查起。

先確認新 CQE，再查是否應通知；最後核對 Host 是否處理並釋放空間。

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

完成已存在、mask=1 且 Host 用輪詢處理，是可以成立的正常案例；中斷不是完成有效性的唯一證據。

如果 Phase 不匹配、查錯 CQ 或漏更新 Head，先修正 Host 證據；不能只因未收到 interrupt 就判 SSD 丟命令。

用同一次測試的設定快照與時間線互相比對，避免拿測試後讀值解釋測試中行為。