DOE 與元件量測、認證

想取得元件的安全量測資料，先如何交換物件？

要查支援哪些協定，如何走訪 Discovery？

先從同一個 Function 的 Extended Capability List 找到 DOE（Data Object Exchange，資料物件交換）實例。每個實例都必須支援 DOE Discovery，但一個 Function 可以有多個實例，各自支援的協定也可能不同。DOE 使用 Configuration Request；Function 不能透過它直接對另一個 Function 發起 P2P 交換。

【模擬資料】以下資料為教學用途建立，不代表特定硬體或平台。假設此實例的起點為 D、目前可接收物件，且本次由一個軟體工作者獨占使用。Figure 6-38 的物件前兩個 DWORD 是標頭；Figure 6-41／Table 6-30 定義 Discovery Request 的第三個 DWORD。

先查 Index=00h，並把三個 DWORD 依序寫入 D+10h 的 Write Data Mailbox。確認全部寫完後，對 D+08h 的 DOE Go 寫 1，才開始處理。DOE Busy=1 時寫 Go，或物件尚未寫完就寫 Go，行為為 undefined（規格未定義）。Go 讀回固定為零，不能靠它判斷處理完成。

Figure 6-40 的 Length 單位是 DWORD，包含兩個標頭；編碼 00000h 特別表示 2¹⁸ DWORD，並非零長度。若實際傳送的 DWORD 數與宣告長度不符，除協定另有規則外，物件須被靜默丟棄；不能假定一定會收到正常回覆。

PCIe Base 6.0 §§6.30–6.30.1.1，Figures 6-38–6-41、Tables 6-28–6-30，印刷／PDF pp.843–846；§7.9.24.3，Figure 7-361／Table 7-315，p.1297。

回覆準備好後，每個 DWORD 要怎麼取走？

以同一個模擬實例為例，假設 DOE Interrupt Enable=0，軟體輪詢 D+0Ch 的 Status。Busy 是 bit0、Error 是 bit2、Data Object Ready 是 bit31；它們代表不同狀態。假設處理後讀到 80000000h：Ready=1、Busy=0、Error=0，表示有物件可讀。

依 §7.9.24.6，每次從 D+14h 的 Read Data Mailbox 讀出目前 DWORD，接著對同一 Register 寫入任意值，確認移出這個 DWORD；下一次讀取才會取得下一個。假設回覆如下：

Header 的 Length=3 確認這個回覆共三個 DWORD。再依 Figure 6-42／Table 6-31 解碼內容：Vendor ID=0001h、Data Object Protocol=00h、Next Index=01h。Index 00h 描述 Discovery 本身；Next Index=01h 告訴軟體下一次查詢要將 Request 內容改成 00000001h。

假設 Index 01h 的回覆內容為 00010001h，表示 Vendor ID=0001h、Protocol=01h（CMA/SPDM）、Next Index=00h，走訪至此結束。索引只在這個實例的 Discovery 清單中有意義，不固定代表某個協定。若 Vendor ID=FFFFh，Index 無效或超出範圍，其他兩個欄位為 undefined，不可拿 Next Index 繼續走訪。

CMA

Component Measurement and Authentication，元件量測與驗證

SPDM

Security Protocol and Data Model，安全協定與資料模型

最後一個 DWORD 也要寫入確認；如果沒有其他物件等候，硬體才清 Ready。若有多個物件連續可讀，Ready 可以保持為一。讀取後漏掉確認，會再次讀到同一個 DWORD；Ready=0 時的讀值 00000000h 也不是一筆可用資料。

PCIe Base 6.0 §6.30.1.1，Figure 6-42／Tables 6-31–6-32，印刷／PDF pp.846–847；§§7.9.24.4–7.9.24.6，pp.1297–1299。p.1299 的 Figure 7-364 和 Table 7-318 標題印為 Write Data Mailbox；本節欄位與正文定義的是 Read Data Mailbox。

看到 Error 時，如何回到可接收狀態？

DOE Error 是唯讀狀態，不是 Write 1 to Clear。軟體對 D+08h 的 DOE Abort 寫 1，實例須在一秒內清除 Error 與 Ready；Abort 讀回固定為零。Abort 後 Busy 仍可能暫時為一，須等它清除，才能再次送出物件。若同一個實例可能由多個軟體工作者使用，還須在完整 request／response 交換期間協調所有權。

對 request／response 協定，若沒有協定專屬時限，§6.30.2 要求從 Go 起一秒內完成處理並在需要回覆時設 Ready；否則同一時限內須設 Error。這是裝置的規格要求，單次輪詢看到 Busy 並不足以推論已逾時。FLR 會中止進行中的 DOE transfer，但不必然重設內部處理引擎。

FLR

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

DOE Interrupt Status 是另一個 RW1C 狀態；清它不等於清 DOE Error。中斷是否存在、是否啟用及向量選擇要另查 DOE Capabilities、Control 和 MSI／MSI-X 設定。DOE 層錯誤與所承載的協定錯誤也要分開判讀。

MSI

Message Signaled Interrupt，訊息中斷

MSI-X

Message Signaled Interrupts Extension，表格式訊息中斷

PCIe Base 6.0 §6.30.2，印刷／PDF pp.847–848；§§7.9.24.2–7.9.24.4、Tables 7-314–7-316，pp.1296–1298。

物件成功交換，接收端就值得信任了嗎？

還要看SPDM（定義安全交換內容與程序的協定）與平台信任政策。Figure 6-43把協定、secured messages與DOE／MCTP承載方式分層。§6.31明確說明：Base處理PCIe特定要求，基礎架構、訊息與協定定義在所引用SPDM文件。

這章因此停在分工與判讀入口：交換成功只證明資料傳輸完成；認證還要驗證身分、量測與信任依據。本文不另編一套憑證驗證演算法，也不把新版SPDM要求偷偷套進Base 6.0。

版本與來源

本章以 PCI Express Base Specification Revision 6.0（6.0-1.0-PUB）為準，文件頁與 PDF 頁相同。案例的配置與讀值均為作者假設，並非實機測量。