韌體、ACPI 與 OS 的控制權

1. UEFI、ACPI、PCI Firmware，為什麼需要三種規格？

UEFI

Unified Extensible Firmware Interface，統一可延伸韌體介面

在 UEFI boot services 環境，PCI Device Driver 用 PCI I/O Protocol 存取其控制器的 Memory、I/O 與 Configuration Space；PCI Bus Driver 則處理 PCI 控制器的裝置 handle。讀 UEFI §14.3.7–§14.4 時要注意：枚舉的晶片組細節具有平台相依性，不能把這個軟體介面章節當成每個 Host Bridge 的硬體程式設計手冊。

若想追查整條 PCI bus 的存取抽象，入口是 PCI Root Bridge I/O；若想追查一個已提供給驅動的 PCI controller，入口是 PCI I/O。這裡只建立閱讀位置，不展開完整 API 實作。OS 的 native driver 也不等於開機前的 UEFI driver。

2. OS 開始執行時，能假設所有 PCI 裝置都已配置嗎？

不能。PCI Firmware 3.3 §3.5 要求韌體配置所有 Host Bridges，因為其硬體程式設計模型不是 PCI 規格統一定義；通往開機與主控台裝置的 PCI-to-PCI Bridges 也必須配置。其他路徑則可能尚未完成，因此 OS 不能只憑「開機成功」推定每張卡都已準備好。

對已配置的 BAR，OS 還要確認對應 I/O／Memory Enable 等交接條件及平台位址轉譯；CPU 用的位址不一定等於 BAR 內的值。這個判讀已在 Chapter 4 建立，本章只補上責任：UEFI driver 與 application 不得自行更改由韌體配置者持有的 BAR／Bridge 資源配置。OS 接手後的配置政策，也必須遵守平台可提供的範圍。

韌體應在 ACPI namespace 描述 Host Bridge，包括 _HID／_CID、_CRS 等資訊。_SEG 用來區分 PCI Segment Group；如果省略，需依其定義處理，不能把 BDF 自動當成全系統唯一識別。PCI Express Host Bridge 的 _HID／_CID 配對見 Firmware §4.1.5；namespace 的路徑與 Bus:Device.Function 是不同的識別系統。

BDF

Bus／Device／Function，匯流排、裝置與功能識別

3. MCFG、_CRS 與 BAR 都有位址，差別在哪裡？

先問位址的用途。MCFG 描述特定 Segment／Bus 範圍的 memory-mapped Configuration Space 存取位置；_CRS 描述 Host Bridge 當前消耗與向下游提供的資源；BAR 則描述某個 Function 的裝置資源。MCFG 不是「可供 BAR 任意分配的記憶體池」。

依 Firmware 3.3 §4.1.4，MCFG 的 Base Address 即使 Start Bus 非零，仍以 Bus 0 為基準。本例先確認目標在 0x40–0x4F 內，再算：

0xE0000000 + (0x42 << 20)
             + (0x03 << 15) + (0x01 << 12) + 0x180
= 0xE4219180

這個 entry 實際涵蓋的 ECAM 位址是 0xE4000000–0xE4FFFFFF，共 16 MiB。不能把 Bus Number 先減 Start Bus；那會算出 0xE0219180。也不能因 Base 是 0xE0000000，就推定前面沒有涵蓋的區域可用於其他目的。

再假設 _CRS 向下游提供 Memory 範圍 0x90000000–0x90FFFFFF，且本例沒有位址轉譯。位於其中的 BAR 候選區間仍要檢查對齊、大小、其他裝置占用與每層 Bridge Window；只在 _CRS 範圍內不等於已完成配置。反過來，剛算出的 ECAM 位址也不能寫進某張卡的 BAR 來「讓設定空間可達」。

MCFG 主要描述開機時已存在的相關 Host Bridges；對支援 Host Bridge 熱加入的情況，Firmware §4.1.3 另定義 _CBA。不要把「一般 PCIe Endpoint 熱插入」與「新增整個 Host Bridge」混為同一種平台描述更新。

4. 找到 Hot-Plug 或 AER 欄位後，OS 就可以修改嗎？

還要確認控制權。PCI Host Bridge 的 _OSC（Operating System Capabilities）讓 OS 宣告支援能力，並要求管理特定功能。它作用於該 Host Bridge 所起始的整個 hierarchy，不是對每個 Endpoint 各發一份授權。

先讀 PCI Firmware 3.3 §4.5.1 的介面識別：UUID 為 33DB4D5B-1FF7-401C-9657-7441C03DD766，Revision=1，Capabilities Buffer 有三個 DWORD。這三個 DWORD 的位元編號各自重新從 0 開始，不能把不同 DWORD 的 bit 7 混在一起。

控制權的回傳 1，不證明硬體一定有那個 Capability。Firmware §4.5.1 明確要求：韌體不能只因自己未明確支援某功能，就隨意拒絕 OS；OS 仍須到每個 Slot／Function 查能力。控制權的回傳 0，也不一定表示硬體沒有實作，可能是平台不允許 OS 接管。

5. 想同時管理 Hot-Plug、PME、AER 與 DPC，要要求哪些 bit？

PME

Power Management Event，電源管理事件

從 Table 4-5 的輸入欄位先建立相依關係，再用 Table 4-6 的回傳定義確認責任。不能只看兩張表相同的 bit 編號，就假定輸入與輸出每一項都完全同義。

所以本例 Control 請求為 (1 << 0) | (1 << 2) | (1 << 3) | (1 << 4) | (1 << 7) = 0x9D。Support=0x9F，表示 OS 宣告 bits 0–4 與 bit 7 的能力：Extended Config operation regions、ASPM、Clock PM、Segment Groups、MSI，以及 Error Disconnect Recover。本例沒有宣告其他 Support 位元，也未請求 LTR、Completion Timeout 或 SFI 控制權。

MSI

Message Signaled Interrupt，訊息中斷

LTR

Latency Tolerance Reporting，延遲容忍度回報

如果韌體保留 DPC Configuration 的所有權，就必須同時保留 AER。反過來，授予 DPC 時須同時授予 AER 與 PCI Express Capability Structure。bit 4 的概括名稱不能用來推翻 bit 3、bit 7 的明確授權限制；Table 4-6 的個別條款與 §4.5.2.4 要一起閱讀。

Support 的 ASPM bit 與 Control 的 native PME bit 也不能互換：前者宣告 OS 的設定能力，後者要求管理 PME 事件。Chapter 10 的 L1.2 是否能啟用，仍要檢查硬體、平台條件與適用的 LTR 等控制權。

LTR

Latency Tolerance Reporting，延遲容忍度回報

6. 第一次 Query 被遮罩，要怎麼讀下一步？

作者情境：韌體已知此平台的 DPC 在 OS 原生控制下有相容性問題，因此保留 DPC 與 AER；允許 OS 管理 Hot-Plug、PME 與相應 PCIe Capability。假設沒有其他授權歷史，也沒有呼叫失敗或 UUID／Revision 錯誤。下表的 Support 始終是 0x0000009F，UUID／Revision／Count 也不變。

第一次的差異為 0x9D & ~0x15 = 0x88，正是 AER bit 3 與 DPC bit 7。回傳 DWORD 1 的 0x10 是 Capabilities Masked，不是「全部不支援」，也不是成功授予原本所有要求。第二次把請求調整成 0x15，Query 不再被遮罩；這時仍只是協商結果。

Query Support Flag=1 時，韌體不得因這次呼叫改動硬體設定。規格強烈建議先 Query，直到 Capabilities Masked 清除；本例之後才清 Query bit，正式要求接管，並重新檢查回傳結果。只有第三列完成後，才能按本例的有效結果判定 OS 已取得那三項控制權。

若回傳有失敗、UUID 或 Revision 錯誤，不能仍把未變的 Control Buffer 當成成功授權。本例把這些錯誤排除，是為了集中解釋遮罩協商，不代表它們可在實際判讀時忽略。

7. 控制權交出去以後，韌體與 OS 各自還能做什麼？

Hot-Plug 授權包含責任交接：韌體須安排事件走原生 device interrupt 路徑；交接後，不再更新插槽的指示燈、電源控制等狀態。PME 授權也有對應的事件路由與 Register 限制。這能避免兩個管理者同時修改同一組狀態。

同一次開機、同一 Host Bridge 的後續 _OSC 呼叫，OS 必須保留先前宣告的支援與已取得的控制請求；韌體也不得收回已授予的控制權。PCI Firmware 3.3 這套介面沒有讓 OS 自行放棄已取得控制權的機制，不能把一般 ACPI 的可能用法直接套進來。

DPC 仍由韌體管理，OS 為什麼可以清除部分狀態？

PCI Firmware 3.3 的 Table 4-6 對 EDR（Error Disconnect Recover，錯誤斷線恢復協作）設有特定例外。它允許 OS 在指定對象與時間窗內處理部分 Status；AER Mask、Severity 與 DPC Control 的設定權仍留給原本的管理者。

先處理觸發 Port，再處理下游 Function

從 Table 4-6 bit 7 的第一段例外讀起：EDR Notify 開始後，到 OS 呼叫對應 _OST 之前，OS 可以寫入觸發 Port的 Device Status 與列明的 AER Status，也可以處理該 Port 的 DPC Trigger Status。在這段期間，韌體不得同時寫入規定的狀態。原表另列 Root Error Status 與 RP PIO Status；它們仍須符合 Port Type 與能力的適用條件，本例不把 Root Port 專用欄位套到 Switch Port。

本例 02:01.0 的 DPC base=0x300。OS 先保存有效紀錄，等 Link Status 的 Data Link Layer Link Active 讀為 0，再依恢復流程以 16-bit 寫入 0x0001 到 0x308，清除 DPC Trigger Status。這個允許寫入的例外，沒有免除 Base 6.0 的硬體條件；若對象是支援 RP Extensions 的 Root Port，還須等 DPC RP Busy=0。

Chapter 12 曾示範原生管理者先寫 0x0008 清 DPC Interrupt Status，再解除隔離。這裡不能直接照搬：本例的有限例外只允許 OS 處理 Port 的 DPC Trigger Status，並未授予 DPC Interrupt Status 或整份 DPC Control 的修改權。權限核對完成後，才套用欄位的寫入方法。

接著看 Table 4-6 的下一頁。OS 呼叫 _OST 時，前面的 Port 通知處理窗口就已結束；等對應 _OST 返回後，才開始下游 Function的指定狀態處理窗口。本例是 03:00.0 的 Device Status、AER Uncorrectable Error Status 與 Correctable Error Status，持續到這個 Function 重初始化完成或被停用為止。規格也對適用 Function 列有 DPC 狀態例外，但不能因此假設普通 Endpoint 一定實作 DPC。

各自窗口內，韌體也必須遵守對應的禁止寫入規則，以免兩邊同時修改相同狀態。普通執行期間的控制權，則依 _OSC 結果維持原有分工；完成 EDR 不會自動把 AER 或 DPC 授予 OS。

實際通知的是哪個 Port，也要先確認

§4.6.13 說明，EDR Notify 可以送到真正觸發 Port 的上層物件。若該通知對象提供定位用的 _DSM，OS 須使用它確認受隔離的 Port；若沒有，才按規則視通知對象本身為觸發 Port。本例假設已完成這一步，不能只把通知物件的名稱直接換成 02:01.0。

另有一條與上圖分開的路徑：若之後處理的熱移除發生在 DPC Trigger Status 仍為 1 的 Port 下，Table 4-6 也允許 OS 處理該 Port 的 Trigger Status。這項例外只涵蓋條文列明的處理情境，不能延伸成一般執行期間任意寫 DPC 的權限。

8. 把位址、管理者與控制權接起來