從 _OSC 結果確認管理者，再以 EDR 時序圖區分觸發 Port、下游 Function 的狀態處理窗口。
read more
PCIe Chapter 13：韌體、ACPI 與 OS 的控制權
先看本章的角色與路徑
作者依 PCI Firmware 3.3 繪製的交接示意；控制範圍由實際回覆與依賴條件決定。
韌體先建立開機環境，OS 再依平台描述與控制權協商接手管理。本章把 Host Bridge 資源描述、設定空間位置與 _OSC（Operating System Capabilities，作業系統能力協商方法）串成一條閱讀路線。
前情提要：BAR 與 Bridge Window 的計算回到 Chapter 4；Hot-Plug、PME、AER 與 DPC 的硬體機制已在前章建立，現在確認由誰管理。
- BAR
- Base Address Register，基底位址暫存器
- PME
- Power Management Event，電源管理事件
- AER
- Advanced Error Reporting，進階錯誤回報
- DPC
- Downstream Port Containment，下游連接埠錯誤隔離
規格路線：Firmware 3.3 §3.5 的交接要求 → §4.1 的平台描述 → §4.5.1 的 Support／Control 欄位 → Query、Control 與依賴條件。
找到 PCIe 欄位，不代表目前的軟體有權設定它。韌體先建立開機環境，OS 再依平台描述與協商結果管理資源及功能。本篇分清 UEFI、ACPI、PCI Firmware 的角色，並以非零 Start Bus 的 ECAM 與 _OSC 協商案例說明常見誤判。
- UEFI
- Unified Extensible Firmware Interface，統一可延伸韌體介面
依問題選擇規格
| 文件 | 本篇使用範圍 |
|---|---|
| UEFI 2.11 §14 | PCI Bus／Device Driver、Root Bridge I/O 與 PCI I/O 的軟體介面入口。 |
| ACPI；PCI Firmware 3.3 §3–§4 | Host Bridge 的平台描述、_CRS 與 _OSC，以及 PCI 專用使用規則。 |
| PCIe Base 6.0 | Capability、Register、事件與交易的硬體語意。 |
UEFI 的 PCI Device Driver 在 boot services 環境透過 PCI I/O 使用控制器；PCI Bus Driver 建立控制器的 device handles。Root Bridge I/O 則是追查整條 bus 存取抽象的入口。這些介面不取代晶片組相依的枚舉細節，也不表示 OS native driver 就是 UEFI driver。
交接不保證每個裝置都已配置
Firmware §3.5 要求韌體配置所有 Host Bridges，以及通往開機／主控台裝置的 PCI-to-PCI Bridges；OS 不能假定其他路徑也都完成。UEFI drivers／applications 不得自行變更由韌體配置者持有的 BAR／Bridge 配置。OS 判讀既有 BAR，仍需對應 Enable 與平台轉譯資訊，CPU 位址未必等於 BAR。
- BAR
- Base Address Register，基底位址暫存器
Host Bridge 在 ACPI namespace 中提供 _HID／_CID、_CRS 等描述，並依條件提供 _SEG 等資訊。Segment 與 BDF 須一起辨識目標；namespace 路徑不是 BDF。依據：PCI Firmware 3.3 §3.5（pp.34–37）、§4.1.5（pp.45–46）；BAR 細節見 Chapter 4。
- BDF
- Bus／Device／Function，匯流排、裝置與功能識別
MCFG 提供設定存取位置，_CRS 限定資源範圍
| 項目 | 值 |
|---|---|
| MCFG Base Address／Segment | 0xE0000000／0x0002 |
| Start Bus／End Bus | 0x40／0x4F |
| Bus／Device／Function／Offset | 0x42／0x03／0x01／0x180 |
| 設定存取位址 | 0xE4219180 |
先選對 Segment entry、確認目標 Bus 在範圍內，再以 Bus 0 為基準計算：0xE0000000 + (0x42 << 20) + (0x03 << 15) + (0x01 << 12) + 0x180 = 0xE4219180。這個 entry 涵蓋 0xE4000000–0xE4FFFFFF，共 16 MiB；不能先減 Start Bus 而算成 0xE0219180，也不能推定 Base 到實際範圍之前的區域可用。
假設 _CRS 提供下游 Memory 範圍 0x90000000–0x90FFFFFF、無轉譯；BAR 仍須檢查大小、對齊、占用與沿途視窗。ECAM 不是可分配給 BAR 的資源池。MCFG 與 Host Bridge 熱加入時的 _CBA 也有不同用途，不要混成一般 Endpoint 熱插入。
閱讀路徑
Firmware Table 4-1（p.39）→ Tables 4-2、4-3（pp.41–42）→ §4.1.4（pp.44–45）。_CBA 見 §4.1.3（pp.42–44）；_CRS 見 §3.5（pp.35–37）、§4.3.2（p.47）。
宣告支援、要求控制與實際授權是三件事
PCI Host Bridge 的 _OSC 涵蓋該 Host Bridge 所起始的 hierarchy。Firmware §4.5.1 定義 UUID=33DB4D5B-1FF7-401C-9657-7441C03DD766、Revision=1、三 DWORD Buffer。DWORD 1 放通用 Query／回傳資訊；DWORD 2 是 OS 單向宣告的 Support Field，回傳修改不作授權；DWORD 3 是 Control 請求與回覆。
送入 DWORD 1 bit 0=1 是 Query，清除才要求接管；回傳 bit 0 是 Reserved。回傳 bit 1、2、3 分別是處理失敗、UUID 不識別、Revision 不識別，bit 4 是 Capabilities Masked。發生錯誤時，不可把保留的 Control bit 當成成功授權。
授權 1 不證明每個裝置都有該能力；回傳 0 也不等於硬體沒有實作。韌體不能只因自己未支援功能就任意拒絕；應有明確的平台不相容依據。OS 仍須查每個 Slot／Function。
介面與通用欄位
Firmware §4.5.1（pp.48–49）、Tables 4-4–4-6（pp.49–58）。通用 bit 定義補充依 ACPI 6.6 §6.2.12官方索引摘錄（文件 p.401）；全文未取得，不延伸到其他 ACPI 行為。Firmware §4.5.3（pp.61–62）亦示範 0x10 遮罩回報。
用相依條件解讀一次完整協商
本例要求 native Hot-Plug bit 0、native PME bit 2、AER bit 3、PCI Express Capability Structure bit 4 與 DPC bit 7，Control=0x9D。DPC 還要求 Support bit 7 的 Error Disconnect Recover（EDR）支援。Support=0x9F 宣告 bits 0–4 與 bit 7：Extended Config operation regions、ASPM、Clock PM、Segment Groups、MSI、EDR。未請求 LTR、Completion Timeout 或 SFI。
- PME
- Power Management Event，電源管理事件
- AER
- Advanced Error Reporting，進階錯誤回報
- DPC
- Downstream Port Containment，下游連接埠錯誤隔離
- MSI
- Message Signaled Interrupt，訊息中斷
- LTR
- Latency Tolerance Reporting，延遲容忍度回報
Hot-Plug、PME、AER 需搭配 Control bit 4；DPC 另需 Control bit 3。韌體保留 DPC 時必須保留 AER；授予 DPC 則須同時授予 AER 與 Capability。bit 4 的概括名稱不能推翻個別控制權。Support ASPM 也不等於 Control PME，更不替代 L1.2 的硬體、時序與 LTR 條件。
- LTR
- Latency Tolerance Reporting，延遲容忍度回報
| 階段 | 輸入 DWORD 1／Control | 回傳 DWORD 1／Control |
|---|---|---|
| 第一次 Query | 0x00000001／0x0000009D | 0x00000010／0x00000015 |
| 調整後 Query | 0x00000001／0x00000015 | 0x00000000／0x00000015 |
| 正式接管 | 0x00000000／0x00000015 | 0x00000000／0x00000015 |
Support 始終為 0x0000009F；假設平台已知 native DPC 有相容性問題，沒有其他錯誤或先前授權。0x9D & ~0x15 = 0x88 表示 AER／DPC 被遮罩。Query 不得因呼叫改動硬體；規格強烈建議 Query 到不再 Mask。第二列仍不是接管，第三列才按有效結果轉移 Hot-Plug、PME 與相應 Capability 的控制權。
相依與呼叫順序
Firmware Tables 4-4–4-6（pp.49–58）、§4.5.2（pp.59–60）、§4.5.3（pp.61–62）。本例政策是作者假設，不是複製規格 ASL 平台範例。
交接後的責任，以及有限的 EDR 例外
授予 Hot-Plug 時，韌體須安排原生事件路由，之後不再更新插槽指示燈與電源狀態；PME 也有相應路由與 Register 限制。同次開機、同一 Host Bridge 的後續呼叫須保留已宣告支援與已取得的請求，韌體不能收回已授權項目；Firmware 3.3 沒有讓 OS 自行放棄已取得控制權的機制。
DPC 仍由韌體管理，OS 為什麼可以清除部分狀態？
PCI Firmware 3.3 的 Table 4-6 對 EDR（Error Disconnect Recover，錯誤斷線恢復協作）設有特定例外。它允許 OS 在指定對象與時間窗內處理部分 Status；AER Mask、Severity 與 DPC Control 的設定權仍留給原本的管理者。
【模擬資料】以下情境為教學用途建立，不代表特定硬體或平台。沿用本章正式 _OSC 呼叫後的 Control=0x00000015、Support=0x0000009F。OS 取得 native Hot-Plug、PME 與相應 PCI Express Capability 的控制權；AER 與 DPC 由韌體保留。另設本例位於 Segment 0，觸發 DPC 的 Switch Downstream Port 是 02:01.0，下游 Endpoint Function 為 03:00.0。
假設平台已依 §4.6.12 完成所需的 EDR／DPC _DSM 協調，沒有 SFI 介入。韌體與 OS 決定嘗試恢復，卡片仍在，OS 也已確認實際觸發的 Port，並完成適用的驅動停止與軟體狀態檢查。到 Switch 的上游管理路徑可用；下游 Function 則需等 Link 與設定存取條件恢復後才能處理。下圖只整理這條恢復路徑的狀態寫入範圍。
時間由上往下。EDR Notify 到呼叫 _OST 之前，與 _OST 返回後，是兩段不同的窗口。_OST 是 OS 向韌體回報本次通知處理結果的方法；不要把「開始呼叫」與「已返回」合成同一個時點。窄螢幕可左右滑動查看兩個對象。
先處理觸發 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。
| 目前階段 | 本例正在處理的對象 | OS 的適用動作 | 仍需保留的限制 |
|---|---|---|---|
| EDR Notify 後、呼叫 _OST 前 | 觸發 Port 02:01.0 | 保存證據，處理列明 Status；符合硬體條件後清 Trigger Status。 | 不能順便改 AER Mask、Severity 或 DPC Control。 |
| _OST 正在執行，尚未返回 | 韌體正在處理這次回報 | 本例等待方法返回。 | 不能沿用已結束的 Port 例外，也不能提前使用返回後才開始的 Function 例外。 |
| _OST 返回後、03:00.0 重初始化完成或停用前 | 下游 Function 03:00.0 | 在可存取且紀錄有效的條件下，處理該 Function 的指定 Device／AER Status。 | 這個窗口沒有把 02:01.0 的完整控制權轉交給 OS。 |
| 03:00.0 的重初始化已完成 | 本次 Function 的例外結束 | 回到原先控制權分工。 | 本次 Function 恢復例外已結束；AER／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 的權限。
控制權例外與硬體條件，要分別查哪份規格？
PCI Firmware Specification Revision 3.3：Table 4-6 Interpretation of the _OSC Control Field, Returned Value，Control bit 7（PDF／印刷 pp.56–57），先辨認觸發 Port、下游 Function，以及 Notify、_OST 呼叫、返回和 Function 重初始化的時間界線。§4.6.12 _DSM for Downstream Port Containment and Hot-Plug Surprise Control（pp.82–84）定義本例假設已完成的協調；其中的 DPC Event Handling Implementation Note（pp.85–86）以未編號流程圖說明恢復路線，不能為它自行加 Figure 編號。§4.6.13 _DSM for Locating the Port that Experienced the Containment Event（pp.87–88）確認通知對象與觸發 Port 的定位方式。這些是 Firmware 3.3 的規則，並非 Base 6.0 所定義的軟體授權介面。
PCI Express Base Specification Revision 6.0：§6.2.11 Downstream Port Containment (DPC)（p.694）、Figure 7-300／Table 7-264 DPC Status Register、§7.9.14.4（pp.1252–1253），確認 Trigger Status 的寫入及釋放所需的 Link inactive／適用 RP Busy 條件。上述兩份文件在本段引用處，PDF 與印刷頁碼相同。完整欄位流程連回 Chapter 12；EDR 的平台政策與失敗恢復不在本段完整展開。
本節前段交接責任與後續 _OSC 呼叫仍依 Firmware Table 4-6（pp.53–57）、§4.5.2.2–§4.5.2.3（p.59）。未提供 _OSC 的 Host Bridge，依 §4.5.1（p.49）處理本介面所定義功能的啟用限制。
確認三類證據沒有混用
Support bit 7=1 就代表 DPC 歸 OS 管理嗎？
沒有；它宣告 EDR 支援，仍需合法 Control 請求、相依功能及非 Query 的有效授權。依據：Tables 4-4–4-6。
MCFG 存取成功、_OSC 也成功，可以忽略 _CRS 不足嗎？
不能。設定存取、控制權與資源容量是不同問題。依據：Firmware §3.5、§4.1、§4.5。
Comments