NVM Express Base 2.4NVM Command Set 1.3NVMe over PCIe Transport 1.4
先跟著一個情境讀規格
以下回傳資料均為教學假設。先看需求與已知條件，再沿閱讀路線找到相關欄位，接著一起判讀結果。完整解說直接顯示，來源細節可另外展開。
練習 01能枚舉 PCIe 裝置，為什麼還不能開始 I/O？
系統已讀到 PCI Vendor ID、Device ID，便宣稱 NVMe 已就緒。還缺哪些層次的證據？
模擬回傳與已知條件
- PCI configuration 的 CMD.MSE=0、CMD.BME=0；BAR 已有配置值。
- 尚未確認 NVMe CAP、CC、CSTS，也沒有 Admin Queue 或 Identify 成功紀錄。
沿著欄位一步步理解
查詢次序：PCI configuration → BAR 與 PCI CMD → NVMe memory-mapped properties → Admin Queue／Identify → I/O queues 與 namespace。
- BAR
- Base Address Register，基底位址暫存器
推導 1PCI configuration 能被讀取，只證明目前可取得該 function 的組態資訊。MSE 控制 memory space 存取，BME 關係到裝置發起的 memory transactions；本例仍未完成這些正常操作條件。
推導 2接著才是 NVMe 自己的 CAP 能力、CC 配置與 CSTS 狀態，以及 queue 記憶體位置。PCI CMD、NVMe CC、Identify Controller 是不同介面的資料，不能用其中一個欄位替代另外兩層。
推導 3這題不要求實際啟用硬體，而是建立盤點順序。只讀識別碼無法回答可用 LBA 格式、Sanitize 方法或 namespace 數量；那些問題還需要 NVMe 命令回覆。
- LBA
- Logical Block Address，邏輯區塊位址
完整原文定位
- PCIe Transport 1.4 · §3.8.1.2 · Figure 12 · Offset 04h: CMD - Command · 文件頁 17 · PDF 17
- PCIe Transport 1.4 · §3.8.1.10 · Figure 20 · Offset 10h: MLBAR (BAR0) – Memory Register Base Address, lower 32-bits · 文件頁 19 · PDF 19
- Base 2.4 · §3.1.4.1 · Figure 36 · Offset 0h: CAP – Controller Capabilities · 文件頁 55–58 · PDF 81–84
- Base 2.4 · §3.1.4.5 · Figure 41 · Offset 14h: CC – Controller Configuration · 文件頁 60–63 · PDF 86–89
- Base 2.4 · §3.1.4.6 · Figure 42 · Offset 1Ch: CSTS – Controller Status · 文件頁 63–65 · PDF 89–91
接著看其他情境
練習 0264-bit BAR 與 doorbell offset 要怎麼合起來？
記錄工具只保存 BAR0，將 queue 3 的 doorbell 算到 4 GiB 以下。請從原始配置重新定位。
模擬回傳與已知條件
- BAR0=40000004h，類型已確認為 64-bit memory BAR；BAR1=00000002h。
- CAP.DSTRD=2；查詢 queue identifier y=3 的 SQ tail 與 CQ head doorbell。
沿著欄位一步步理解
查詢次序：PCI configuration BAR0／BAR1 → 組成 register base → CAP.DSTRD → 依 queue ID 算 SQ／CQ doorbell offset。
- SQ
- Submission Queue，提交佇列
- CQ
- Completion Queue，完成佇列
推導 1先去掉 BAR0 屬性位再組合：base=(2<<32)|40000000h=0000000240000000h。BAR0 末尾的 4 表示屬性，不是映射起點多 4 bytes。
推導 2stride=4<<2=16 bytes。SQ3 offset=1000h+(2×3)×16=1060h；CQ3 offset=1000h+(2×3+1)×16=1070h。這裡 3 是 queue ID，不是 ring 目前第幾個 entry。
推導 3所以兩個地址是 0000000240001060h 與 0000000240001070h。這只定位暫存器；寫入的 tail／head 數值要由 queue 狀態決定，不能把地址或 byte offset 當作 doorbell 值。
完整原文定位
- PCIe Transport 1.4 · §3.8.1.10 · Figure 20 · Offset 10h: MLBAR (BAR0) – Memory Register Base Address, lower 32-bits · 文件頁 19 · PDF 19
- PCIe Transport 1.4 · §3.8.1.11 · Figure 21 · Offset 14h: MUBAR (BAR1) – Memory Register Base Address, upper 32-bits · 文件頁 19 · PDF 19
- PCIe Transport 1.4 · §3.1.2.1 · Figure 5 · Offset (1000h + ((2y) * (4 << CAP.DSTRD))): SQyTDBL – Submission Queue y Tail Doorbell · 文件頁 10 · PDF 10
- PCIe Transport 1.4 · §3.1.2.2 · Figure 6 · Offset (1000h + ((2y + 1) * (4 << CAP.DSTRD))): CQyHDBL – Completion Queue y Head Doorbell · 文件頁 10–11 · PDF 10–11
- Base 2.4 · §3.1.4.1 · Figure 36 · Offset 0h: CAP – Controller Capabilities · 文件頁 55–58 · PDF 81–84
練習 03RDY=1，為什麼不能直接說所有媒體已準備好？
初始化紀錄在 1 秒時看到 RDY=1，測試便要求所有 namespace 命令立即可用。這忽略了哪個模式？
模擬回傳與已知條件
- Controller 支援並啟用 media-independent ready：CC.CRIME=1；CSTS.RDY=1、CFS=0。
- CRTO.CRIMT=3、CRWMT=12；尚無證據顯示必要媒體均已就緒。
沿著欄位一步步理解
查詢次序：讀 CAP 的 ready 能力、CC.CRIME、CSTS 與 CRTO；將等待目標分為 media-independent ready 與 required-media ready。
推導 1CRIMT=3 與 CRWMT=12 使用 500 ms 單位，對應 1.5 seconds 與 6 seconds。它們是對應模式下的等待上限資訊，不是聲稱每次都必須花滿這些時間。
推導 2在本題啟用的模式，RDY 可先表示 controller 已能處理不依賴媒體的命令。測試必須區分哪些命令需要媒體，而不是把這個 RDY 觀察延伸成所有資料路徑皆已就緒。
推導 3可再用 Identify CNS=08h 讀目標 namespace 的 NSTAT.NRDY：1 才表示該 namespace 已就緒。保存 CC.EN 設為 1 的起點及實際 command status，再與對應 timeout 比較。CFS=0 只是未回報 controller fatal status，不能補足缺少的媒體就緒證據。
完整原文定位
- Base 2.4 · §3.1.4.1 · Figure 36 · Offset 0h: CAP – Controller Capabilities · 文件頁 55–58 · PDF 81–84
- Base 2.4 · §3.1.4.5 · Figure 41 · Offset 14h: CC – Controller Configuration · 文件頁 60–63 · PDF 86–89
- Base 2.4 · §3.1.4.6 · Figure 42 · Offset 1Ch: CSTS – Controller Status · 文件頁 63–65 · PDF 89–91
- Base 2.4 · §3.1.4.21 · Figure 57 · Offset 68h: CRTO – Controller Ready Timeouts · 文件頁 73 · PDF 99
- Base 2.4 · §5.2.14.2.8 · Figure 346 · Identify – I/O Command Set Independent Identify Namespace Data Structure · 文件頁 394 · PDF 420
練習 04裝置支援 x4，現在卻只有 x2？
產品與能力欄位都說支援 x4，效能卻較低。要到哪裡查目前實際 lane 數？
模擬回傳與已知條件
- PCIe link 已 up；Link Capabilities 表示最大 x4；Link Status 的 NLW=2。
- CLS 已記錄，但沒有完整路徑、payload 或 workload 的吞吐資料。
沿著欄位一步步理解
查詢次序：沿 PCI capability 結構找到 PCI Express Capability，讀 Link Capabilities 與 Link Status；這不是 Identify CNS 的回覆。
推導 1能力欄位描述可以支援的最大寬度，NLW 描述目前協商的寬度。因此兩個值並不矛盾：裝置能支援 x4，這次 link 使用 x2。
推導 2這足以指出可用 lane 數低於最大值，但無法單靠 endpoint 的欄位定位是 slot、上游 port、平台配置或其他原因。下一步應比對整條路徑的能力與協商結果。
推導 3CLS 是速度編碼，不能把原始代碼直接當成 GT/s；x2 也不是實測 bandwidth。應先把協商結果與能力分開，再用適用的速度定義及實際測量分析吞吐。
完整原文定位
- PCIe Transport 1.4 · §3.8.5.6 · 文件頁 28–29 · PDF 28–29
- PCIe Transport 1.4 · §3.8.5.8 · Figure 55 · Offset PXCAP + 12h: PXLS – PCI Express Link Status · 文件頁 29 · PDF 29
練習 05CQE 已出現，為什麼 MSI-X 沒通知？
- CQE
- Completion Queue Entry，佇列中的完成項目
- MSI-X
- Message Signaled Interrupts Extension，表格式訊息中斷
主機輪詢看到新 CQE，但中斷處理常式沒有執行。請判斷應先查媒體還是 interrupt 設定。
- CQE
- Completion Queue Entry，佇列中的完成項目
模擬回傳與已知條件
- MSI-X：MXE=1、FM=0、TS=7；目標 CQ 使用 vector 5，該 vector 的個別 mask=1。
- 新 CQE phase 與成功 status 均已確認；尚未解讀 PBA 或 coalescing 設定。
沿著欄位一步步理解
查詢次序：CQ 的 interrupt vector 關聯 → PCI MSI-X Message Control → Table entry mask／PBA → 必要時 Get Features FID=08h 與 per-vector 設定。
- CQ
- Completion Queue，完成佇列
- MSI-X
- Message Signaled Interrupts Extension，表格式訊息中斷
推導 1TS=7 表示 8 個 table entries，所以 vector 5 在範圍內。FM=0 只解除整體 function mask，沒有把個別 vector 的 mask 一併清掉。
推導 2vector 5 仍被遮罩，已提供中斷未送達的一個直接解釋。CQE 的成功 status 與中斷通知是不同觀察：不能因 handler 沒跑，就否定已經看見的完成結果。
推導 3若個別 mask 也已解除，才進一步看 pending、coalescing、主機路由等條件。不要把這個單一分支寫成「所有沒中斷都由 mask 引起」，也不要把 vector 數當成 queue 數。
完整原文定位
- PCIe Transport 1.4 · §3.8.4.2 · Figure 44 · Offset MSIXCAP + 2h: MXC – MSI-X Message Control · 文件頁 24–25 · PDF 24–25
- PCIe Transport 1.4 · §3.8.4.3 · Figure 45 · Offset MSIXCAP + 4h: MTAB – MSI-X Table Offset / Table BIR · 文件頁 25 · PDF 25
- PCIe Transport 1.4 · §3.8.4.4 · Figure 46 · Offset MSIXCAP + 8h: MPBA – MSI-X PBA Offset / PBA BIR · 文件頁 25 · PDF 25
- Base 2.4 · §5.2.30.2.1 · Figure 543 · Interrupt Coalescing – Command Dword 11 · 文件頁 515 · PDF 541
練習 06PCIe AER 與 NVMe AER 是同一種錯誤紀錄嗎？
追蹤檔寫著 AER，但沒註明介面。兩次 PCIe status 都是 1，又能否說新增兩次 NVMe 錯誤？
模擬回傳與已知條件
- PCIe AERCES.RTS 兩次取樣均為 1；兩次之間沒有清除或 reset。
- 另有 NVMe Asynchronous Event Request 的完成紀錄，但尚未比對時間與通知內容。
沿著欄位一步步理解
查詢次序：先辨識資料來自 PCIe Advanced Error Reporting extended capability，還是 NVMe Asynchronous Event Request completion。
推導 1PCIe 的 AER 是 Advanced Error Reporting，這裡的 RTS 是 Replay Timer Timeout 狀態位；NVMe 的 AER 是非同步事件命令。縮寫相同，不代表資料結構、對象或事件意義相同。
推導 2RTS 是狀態位而非次數。未清除時連續看到 1，可能只是同一個仍保留的狀態，不能由兩次取樣算成發生兩次，更不能算成兩筆 NVMe command failure。
推導 3要關聯兩邊，需要各自完整紀錄、時間與裝置身分。PCIe 錯誤可幫忙分析傳輸問題，但不能直接指定是哪個 SQID／CID，也不能代替 CQE 或 NVMe log 的結果。
- SQID
- Submission Queue Identifier，提交佇列識別碼
- CID
- Command Identifier，同一提交佇列內的命令識別碼
完整原文定位
- PCIe Transport 1.4 · §3.8.6.2 · Figure 60 · Offset AERCAP + 4: AERUCES – AER Uncorrectable Error Status Register · 文件頁 31–32 · PDF 31–32
- PCIe Transport 1.4 · §3.8.6.5 · Figure 63 · Offset AERCAP + 10h: AERCES – AER Correctable Error Status Register · 文件頁 33 · PDF 33
- Base 2.4 · §5.2.2 · 文件頁 183–190 · PDF 209–216
01Doorbell 在記憶體映射中的位置
Base 2.4 · Figure 34 · Memory-Based Property Definition
§3.1.4 · 文件頁 54 · PDF 80
01.1 · 用途查 controller properties 後面的空間怎麼排列時，用這張表找傳輸專用區的起點。PCIe 的 doorbell 區從 offset 1000h 開始；這是相對暫存器基底的位置，不是主機實體位址 1000h。
01.2 · 欄位與關係表的 OFST 是位元組偏移，Size 是佔用大小，T 表示由傳輸規格定義。Variable 表示大小隨配置而變，不能假設整區只佔 4 KiB；個別 SQ／CQ doorbell 位址還要用 CAP.DSTRD 計算。
- SQ
- Submission Queue，提交佇列
01.3 · 判讀與例子例如 BAR 映射基底為 80000000h，doorbell 區起點就是 80001000h。要找 queue 2 的 doorbell，繼續查 PCIe Figures 5、6，不能直接在這個起點寫入 queue ID。
搜尋詞：MMIO · doorbell · OFST
- MMIO
- Memory-Mapped I/O，記憶體映射輸入輸出
回本冊圖表索引
02CAP：設定前先查硬體能力
Base 2.4 · Figure 36 · Offset 0h: CAP – Controller Capabilities
§3.1.4.1 · 文件頁 55–58 · PDF 81–84
02.1 · 用途建立佇列、選記憶體頁大小或判斷 ready timeout 前，先查 CAP。它是能力回報，不是目前 CC 的設定值；讀到某能力不代表主機已啟用它。
02.2 · 欄位與關係常查的群組是 MQES bits15:0（最大 queue entries 減 1）、CQR bit16（I/O queue 連續記憶體要求）、DSTRD bits35:32（doorbell 間距 2^(2+DSTRD) bytes）、MPSMIN／MPSMAX bits51:48／55:52（頁大小指數）。CSS bits44:37、NSSRS bit36、CRMS bits60:59 分別查命令集、subsystem reset 與 ready 模式；TO bits31:24 以 500 ms 計。
02.3 · 判讀與例子例如 MQES=03FFh 是最多 1024 entries，DSTRD=1 是間距 8 bytes；兩個值都不能直接當 bytes 使用。選頁大小時還要核對 CC.MPS，等待 ready 則搭配 CC.CRIME、CRTO 與啟用流程。
搜尋詞：CAP · MQES · MPSMIN · MPSMAX · DSTRD · TO · CRMS · CSS
回本冊圖表索引
03CC：主機實際選了什麼
Base 2.4 · Figure 41 · Offset 14h: CC – Controller Configuration
§3.1.4.5 · 文件頁 60–63 · PDF 86–89
03.1 · 用途當能力看來足夠，controller 卻無法正常啟用，查 CC 可核對主機真正寫入的設定。它同時包含啟用、命令集、頁大小、佇列項目大小和 shutdown 通知。
03.2 · 欄位與關係EN bit0 控制啟用；CSS bits6:4 選命令集；MPS bits10:7 指定 2^(12+MPS) bytes；AMS bits13:11 選排程；SHN bits15:14 發 shutdown 通知。IOSQES bits19:16／IOCQES bits23:20 是每項 bytes 的 2 次方指數，CRIME bit24 決定啟用時的 ready 模式。
03.3 · 判讀與例子IOSQES=6、IOCQES=4 分別是 64-byte SQE、16-byte CQE，不是 queue 深度。EN 由 1 清為 0 會引發 Controller Reset；MPS、CSS 等設定有停用時才能修改的條件，不能把這個暫存器當任意時點都能重寫的設定表。
- SQE
- Submission Queue Entry，佇列中的命令項目
搜尋詞：CC · EN · MPS · IOSQES · IOCQES · SHN · CRIME
回本冊圖表索引
04CSTS：啟用與關機進度回報
Base 2.4 · Figure 42 · Offset 1Ch: CSTS – Controller Status
§3.1.4.6 · 文件頁 63–65 · PDF 89–91
04.1 · 用途CC 表示主機要求什麼，CSTS 表示控制器回報什麼。啟用卡住、命令無完成結果或 shutdown 尚未結束時，先把這兩邊對起來。
04.2 · 欄位與關係RDY bit0 表示已準備處理 submission entries；CFS bit1 表示無法由適當 CQ 回報的致命錯誤；SHST bits3:2 區分未開始、進行中與完成；ST bit6 區分 controller 與 subsystem shutdown。NSSRO bit4、PP bit5 另提供 reset 發生與處理暫停資訊。
04.3 · 判讀與例子SHST=10b 表示 shutdown 完成，不是一般 I/O 成功。RDY=1 的可用範圍還受 ready 模式影響；在 media-independent 模式下，不能據此假設所有 namespace 的媒體都已就緒。
搜尋詞：CSTS · RDY · CFS · SHST · ST
回本冊圖表索引
05NSSR：辨識 subsystem reset 要求
Base 2.4 · Figure 43 · Offset 20h: NSSR – NVM Subsystem Reset
§3.1.4.7 · 文件頁 66 · PDF 92
05.1 · 用途分析重設紀錄時，這張表用來辨識是否要求了整個 NVM subsystem reset。支援由 CAP.NSSRS 回報，與只清除單一 controller 的 CC.EN 不同。
05.2 · 欄位與關係offset20h 的 NSSRC bits31:0 只有寫入 4E564D65h 才啟動此 reset；其他值沒有這個功能效果。讀回固定為 0，不能靠讀值找回主機最後寫入的要求。
05.3 · 判讀與例子若 trace 顯示曾寫入 4E564D65h，之後讀 NSSR 得 0 是規格定義行為，不能據此認為寫入沒發生。確認重設完成與影響範圍，仍要搭配狀態與 §3.7.1 的流程。
搜尋詞：NSSR · NSSRC · NSSRS · 4E564D65h
回本冊圖表索引
06AQA：Admin 佇列深度
Base 2.4 · Figure 44 · Offset 24h: AQA – Admin Queue Attributes
§3.1.4.8 · 文件頁 66 · PDF 92
06.1 · 用途Admin commands 一開始就無法提交或回收時，用 AQA 核對兩個 Admin queues 的大小。這裡記的是 entry 數量，不是記憶體容量。
06.2 · 欄位與關係ASQS bits11:0 與 ACQS bits27:16 分別是 submission／completion 深度減 1；中間與高位保留。每個 queue 至少 2、最多 4096 entries，啟用時把其中一個欄位留為 0 會產生未定義結果。
06.3 · 判讀與例子要配置兩個各 64 entries 的 Admin queues，ASQS=63、ACQS=63，AQA=003F003Fh。SQ 與 CQ 的 entry 大小不同，所以相同深度不代表相同 buffer bytes。
搜尋詞：AQA · ASQS · ACQS · queue depth
回本冊圖表索引
07ASQ：Admin 命令佇列基底
Base 2.4 · Figure 45 · Offset 28h: ASQ – Admin Submission Queue Base Address
§3.1.4.9 · 文件頁 66 · PDF 92
07.1 · 用途這張表回答 controller 要從哪裡取 Admin 命令。ASQ 是 Admin Submission Queue 的基底，不是目前待執行命令的地址，也不是 SQ tail。
07.2 · 欄位與關係ASQB bits63:12 保存實體位址的高 52 bits；bits11:0 保留為 0。完整地址還必須依 CC.MPS 的頁大小對齊，因此最低 12 bits 為 0 只是最低要求。
07.3 · 判讀與例子例如 CC.MPS=1 代表 8 KiB pages；地址 00101000h 雖然 4 KiB 對齊，仍不符合這個設定。先核對 AQA 的深度和實際配置範圍，再比較 SQ doorbell 更新。
搜尋詞：ASQ · ASQB · Admin SQ · alignment
回本冊圖表索引
08ACQ：Admin 完成佇列基底
Base 2.4 · Figure 46 · Offset 30h: ACQ – Admin Completion Queue Base Address
§3.1.4.10 · 文件頁 67 · PDF 93
08.1 · 用途Admin 命令已被取走，但主機在錯誤位置等完成結果時，查 ACQ。所有經 Admin SQ 提交的命令，其完成項目都送到這個 Admin CQ。
08.2 · 欄位與關係ACQB bits63:12 是地址高位，低 12 bits 保留；地址按 CC.MPS 對齊。Admin CQ 固定關聯 interrupt vector0，不能把任意 I/O CQ 的向量設定套用過來。
08.3 · 判讀與例子ACQ 基底正確仍不保證每個 entry 都是新結果；讀取端還要看 CQE 的 phase tag，再更新 CQ head doorbell。ACQ 不會隨每筆完成而加 16。
搜尋詞：ACQ · ACQB · Admin CQ · interrupt vector 0
回本冊圖表索引
09CRTO：控制器與媒體就緒的等待時間
Base 2.4 · Figure 57 · Offset 68h: CRTO – Controller Ready Timeouts
§3.1.4.21 · 文件頁 73 · PDF 99
09.1 · 用途這張表用來區分「先能處理不依賴媒體的命令」與「全部必要媒體就緒」兩種等待目標。排查初始化慢，先確定自己正在等待哪一件事。
09.2 · 欄位與關係CRIMT bits31:16 與 CRWMT bits15:0 均以 500 ms 計。前者在支援並啟用 media-independent ready 模式時使用；CRWMT 描述 controller 及必要媒體全部就緒的最長等待時間，且不得小於 CRIMT。
09.3 · 判讀與例子若 CRIMT=4、CRWMT=20，分別是 2 秒與 10 秒。2 秒後某些 Admin 命令已可執行，不代表讀 namespace 應立即成功；仍要看 CC.CRIME 與該命令是否需要媒體。
搜尋詞：CRTO · CRIMT · CRWMT · ready timeout
回本冊圖表索引
10SQ doorbell：告知新的提交位置
PCIe Transport 1.4 · Figure 5 · Offset (1000h + ((2y) * (4 << CAP.DSTRD))): SQyTDBL – Submission Queue y Tail Doorbell
§3.1.2.1 · 文件頁 10 · PDF 10
10.1 · 用途主機把命令放入 SQ 後，用此 doorbell 告知新的 tail。表內的 y 是 queue ID；offset 從 controller register base 起算，不是 SQ buffer 起算。
10.2 · 欄位與關係地址公式為 1000h+(2y)×(4<<CAP.DSTRD)，SQT 在 bits15:0，bits31:16 保留。寫入的是環形佇列的新索引，新增命令數要由前後 tail 差值並考慮回繞計算。
10.3 · 判讀與例子DSTRD=1、y=2 時，offset=1020h。深度 64 的 SQ 若 tail 從 62 走到 1，新增的是 3 項；寫 1 不代表只新增 1 項。
搜尋詞：SQyTDBL · SQT · DSTRD · tail · wrap
回本冊圖表索引
11CQ doorbell：歸還已讀取的位置
PCIe Transport 1.4 · Figure 6 · Offset (1000h + ((2y + 1) * (4 << CAP.DSTRD))): CQyHDBL – Completion Queue y Head Doorbell
§3.1.2.2 · 文件頁 10–11 · PDF 10–11
11.1 · 用途主機讀完 CQE 後，更新 CQ head doorbell，告知哪些位置可供 controller 重用。這個動作不是提交新命令，也不是讀取目前 CQ head。
11.2 · 欄位與關係offset=1000h+(2y+1)×(4<<CAP.DSTRD)，CQH 位於 bits15:0，高位保留。寫入新 head，前後差值需考慮環形回繞；doorbell 讀回值由廠商定義，不適合作為狀態查詢。
11.3 · 判讀與例子DSTRD=1、queue2 的 CQ doorbell 在 1028h，與 SQ 的 1020h 相隔 8 bytes。若只處理完成項目卻沒適時歸還空間，controller 可能沒有可重用的 CQ 位置。
搜尋詞：CQyHDBL · CQH · head · wrap
回本冊圖表索引
12PCI CMD：MMIO 與 Bus Master 的入口
- MMIO
- Memory-Mapped I/O，記憶體映射輸入輸出
PCIe Transport 1.4 · Figure 12 · Offset 04h: CMD - Command
§3.8.1.2 · 文件頁 17 · PDF 17
12.1 · 用途PCIe 裝置可被枚舉，卻不能正常存取暫存器或搬移主機資料時，這張 PCI configuration 表是起點。這裡的 CMD 不是 NVMe command，也不是 NVMe CC。
12.2 · 欄位與關係常查 BME bit2（Bus Master Enable，允許裝置主動發起存取）、MSE bit1（Memory Space Enable，記憶體空間存取啟用）及 IOSE bit0。bit10 為 Interrupt Disable，其餘欄位依 PCI 用途分開判讀。
12.3 · 判讀與例子看見 BAR 地址已配置，不能因此認定 BME／MSE 也已啟用。先核對 PCI 設定，再查 NVMe 佇列地址；把 PCI CMD 與 NVMe CC 的 offset 混用會讀到完全不同資料。
搜尋詞：PCI CMD · BME · MSE · IOSE · MMIO · DMA
- DMA
- Direct Memory Access，裝置直接存取記憶體
回本冊圖表索引
13BAR0：暫存器基底的低位與屬性
PCIe Transport 1.4 · Figure 20 · Offset 10h: MLBAR (BAR0) – Memory Register Base Address, lower 32-bits
§3.8.1.10 · 文件頁 19 · PDF 19
13.1 · 用途從 PCI configuration 找到 NVMe 暫存器映射時，先讀 BAR0 的位址與類型，再判斷是否需要 BAR1 高位。此表也說明位址低位不是全部都能當地址使用。
13.2 · 欄位與關係BA bits31:14 保存低 32-bit 地址中的可設定部分；bits13:4 保留。PF bit3 說明不允許 prefetch，TP bits2:1 表示映射類型，RTE bit0 表示 memory space。更大的映射空間可以使更多地址位唯讀。
- PF
- Physical Function，實體功能
13.3 · 判讀與例子組合地址前要去掉屬性位，並確認 TP 所指類型。64-bit 映射時只取 BAR0 會截斷 4 GiB 以上地址；反過來也不能不看類型便把任意下一個 BAR 當高 32bits。
搜尋詞：BAR0 · MLBAR · BA · TP · PF · RTE
- PF
- Physical Function，實體功能
回本冊圖表索引
14BAR1：64-bit 暫存器地址的高位
PCIe Transport 1.4 · Figure 21 · Offset 14h: MUBAR (BAR1) – Memory Register Base Address, upper 32-bits
§3.8.1.11 · 文件頁 19 · PDF 19
14.1 · 用途確認使用 64-bit 暫存器映射後，這張表提供地址高 32bits。它和 BAR0 是一組地址，不是另一個 NVMe 暫存器區。
14.2 · 欄位與關係BA bits31:0 直接對應完整地址 bits63:32。地址的低位與屬性仍來自 BAR0；主機可用的地址範圍還受到平台與橋接器資源配置限制。
14.3 · 判讀與例子例如有效高位為 1、低位地址部分為 80000000h，組合為 0000000180000000h。忽略高位會誤存取 80000000h，兩者相差 4 GiB。
搜尋詞：BAR1 · MUBAR · BA · 64-bit address
回本冊圖表索引
15MSI-X：總開關、遮罩與向量數
PCIe Transport 1.4 · Figure 44 · Offset MSIXCAP + 2h: MXC – MSI-X Message Control
§3.8.4.2 · 文件頁 24–25 · PDF 24–25
15.1 · 用途CQ 已產生完成項目但未收到中斷時，這張表可確認 MSI-X 是否啟用、是否被整體遮罩，以及硬體提供多少向量。
15.2 · 欄位與關係MXE bit15 為 MSI-X enable，FM bit14 遮罩全部向量，TS bits10:0 為 table entries 減 1。使用 MSI-X 還要求 MSI enable 清 0；FM 清 0 後，個別 vector mask 仍各自有效。
- MSI
- Message Signaled Interrupt，訊息中斷
15.3 · 判讀與例子TS=3 表示 4 個向量，不是向量 3 已被啟用。FM 由 1 改 0 也不會自動清除每個向量自己的 mask，還要配合 CQ 指定的 interrupt vector 查表。
搜尋詞：MSI-X · MXE · FM · TS · interrupt
回本冊圖表索引
16MSI-X Table：先找 BAR，再加 offset
PCIe Transport 1.4 · Figure 45 · Offset MSIXCAP + 4h: MTAB – MSI-X Table Offset / Table BIR
§3.8.4.3 · 文件頁 25 · PDF 25
16.1 · 用途要定位 MSI-X table 以核對向量配置，先由這張表找 BAR，再加 table offset。BAR index 和位址偏移是兩個欄位。
16.2 · 欄位與關係TBIR bits2:0 選 BAR；TO bits31:3 保存 8-byte 對齊的偏移。形成 offset 時清除低 3bits，不能把整個 32-bit 值直接加到 BAR 基底。64-bit BAR 以低 Dword 的 BAR 識別。
16.3 · 判讀與例子若 MTAB=00002004h，TBIR=4、offset=2000h，表示 BAR4 所映射基底加 2000h，而不是 BAR0 加 2004h。可用 BIR 編碼須依本表判斷。
搜尋詞：MTAB · TBIR · TO · MSI-X
回本冊圖表索引
17MSI-X PBA：待處理中斷的資料位置
PCIe Transport 1.4 · Figure 46 · Offset MSIXCAP + 8h: MPBA – MSI-X PBA Offset / PBA BIR
§3.8.4.4 · 文件頁 25 · PDF 25
17.1 · 用途這張表定位 Pending Bit Array，讓你檢查向量是否有待處理的中斷狀態。PBA 與 MSI-X table 是不同結構，不能因為都屬 MSI-X 就使用同一個 offset。
17.2 · 欄位與關係PBIR bits2:0 選 BAR，PBAO bits31:3 給 8-byte 對齊的偏移；算法類似 MTAB，但欄位內容可以不同。這裡描述的是 PBA 位置，並不是各 vector 的 pending bits 本身。
17.3 · 判讀與例子MPBA=00003000h 表示由 BAR0 映射基底加 3000h 取得 PBA。是否已出現 CQE 仍要讀 CQ；一個 pending bit 不能代替 CQ 裡每筆命令的 status。
搜尋詞：MPBA · PBA · PBIR · PBAO · pending
回本冊圖表索引
18PCIe Link：目前談成的速度與寬度
PCIe Transport 1.4 · Figure 55 · Offset PXCAP + 12h: PXLS – PCI Express Link Status
§3.8.5.8 · 文件頁 29 · PDF 29
18.1 · 用途頻寬低於預期時，查這張表確認目前協商出的 link speed 和 width。裝置宣告的最大能力不能代替目前結果。
18.2 · 欄位與關係NLW bits9:4 是 Negotiated Link Width，CLS bits3:0 是 Current Link Speed 編碼；link 未 up 時兩者未定義。SCC bit12 描述是否使用平台提供的共同參考時鐘，不是 link 速度。
18.3 · 判讀與例子若 NLW=2，表示目前是 x2，不能因產品標示 x4 就假設四條 lane 都在用。CLS 需用對應 PCIe 版本的速度編碼解讀；本表沒有完整定義外部 PCIe 速度表，不把編碼值直接當 GT/s。
搜尋詞：PXLS · NLW · CLS · SCC · link speed · link width
回本冊圖表索引
19PCIe AER：不可更正錯誤狀態
PCIe Transport 1.4 · Figure 60 · Offset AERCAP + 4: AERUCES – AER Uncorrectable Error Status Register
§3.8.6.2 · 文件頁 31–32 · PDF 31–32
19.1 · 用途查 PCIe 交易或連結異常時，這張表列出不可更正錯誤狀態。這裡 AER 是 Advanced Error Reporting，不是 NVMe 的 Asynchronous Event Request。
19.2 · 欄位與關係常用欄位包含 CTS bit14（Completion Timeout）、UCS bit16（Unexpected Completion）、MTS bit18（Malformed TLP）、URES bit20（Unsupported Request）及 DLPES bit4（Data Link Protocol Error）。TLP 是交易層封包；多個狀態可同時置位。另有 mask 與 severity 暫存器決定回報和嚴重程度。
19.3 · 判讀與例子CTS=1 只能證明記錄了 PCIe completion timeout，不能直接判定是哪筆 NVMe CID 失敗。保存狀態與 header log 後再對時間、佇列及 CQE；應先保存原始狀態，再進行錯誤復原，避免丟失用來對照的資訊。
- CID
- Command Identifier，同一提交佇列內的命令識別碼
搜尋詞：AERUCES · CTS · URES · MTS · UCS · DLPES · PCIe AER
回本冊圖表索引
20PCIe AER：已更正錯誤與重傳線索
PCIe Transport 1.4 · Figure 63 · Offset AERCAP + 10h: AERCES – AER Correctable Error Status Register
§3.8.6.5 · 文件頁 33 · PDF 33
20.1 · 用途鏈路仍能運作但效能或穩定性下降時，可查已更正錯誤狀態。已更正表示該類錯誤有修復機制，不表示出現頻率不值得觀察。
20.2 · 欄位與關係RES bit0 為 Receiver Error，BTS6／BDS7 為 Bad TLP／Bad DLLP，RRS8 為 replay 編號回捲，RTS12 為 Replay Timer Timeout。這些是狀態位，不是發生次數；遮罩另由 AERCEM 控制。
20.3 · 判讀與例子兩次快照都看到 RTS=1，若中間沒清除，不能推論又新增一次 timeout。要分析發生頻率，需記錄取樣時間、清除行為與重現條件，再與當時的 link 狀態對照。
搜尋詞：AERCES · RES · BTS · BDS · RTS · RRS · correctable
回本冊圖表索引