PCIe Chapter 13: Firmware, ACPI, and OS Ownership

Read platform descriptions, then negotiate runtime control

Firmware establishes the boot environment; the OS uses platform descriptions and control negotiation to take over management. This chapter connects Host Bridge resources, configuration access and _OSC (Operating System Capabilities).

Specification route: PCI Firmware 3.3 Section 3.5 → platform descriptions in Section 4.1 → Support/Control in Section 4.5.1 → Query, Control and dependencies.

Choose the specification by the question

UEFI PCI Device Drivers use PCI I/O in the boot services environment; PCI Bus Drivers create controller device handles. Root Bridge I/O is the entry point for bus-level access abstraction. These interfaces do not replace chipset-specific enumeration details, and an OS native driver is not necessarily a UEFI driver.

Handoff does not imply every device was configured

Firmware §3.5 requires configuration of all Host Bridges and PCI-to-PCI Bridges leading to boot/console devices. The OS cannot assume every other path is configured. UEFI drivers/applications must not change BAR/Bridge assignments owned by the firmware configurator. Existing BAR interpretation still requires the corresponding Enables and platform translation information; CPU and BAR addresses may differ.

BAR

Base Address Register

ACPI Host Bridge objects provide _HID/_CID, _CRS, and conditionally information such as _SEG. Segment and BDF identify the target together; a namespace path is not a BDF. Sources: PCI Firmware 3.3 §3.5 (pp.34–37), §4.1.5 (pp.45–46); BAR details in Chapter 4.

BDF

Bus/Device/Function

MCFG locates configuration access; _CRS bounds resources

Select the Segment entry and check the Bus range, then calculate relative to Bus 0: 0xE0000000 + (0x42 << 20) + (0x03 << 15) + (0x01 << 12) + 0x180 = 0xE4219180. The entry covers 0xE4000000–0xE4FFFFFF, or 16 MiB. Subtracting Start Bus incorrectly produces 0xE0219180. Do not assume anything about the region between the Base and the supported range.

Suppose _CRS provides downstream Memory at 0x90000000–0x90FFFFFF without translation. BAR allocation still requires size, alignment, occupancy, and intervening-window checks. ECAM is not a BAR resource pool. MCFG and _CBA for hot-added Host Bridges also have different roles; Host Bridge addition is not ordinary Endpoint insertion.

Declaring support, requesting control, and receiving ownership are distinct

PCI Host Bridge _OSC applies to its originating hierarchy. Firmware §4.5.1 specifies UUID 33DB4D5B-1FF7-401C-9657-7441C03DD766, Revision=1, and a three-DWORD buffer. DWORD 1 holds generic Query/return information. DWORD 2 is the one-way OS Support declaration; returned changes do not grant control. DWORD 3 carries Control requests and responses.

Input DWORD 1 bit 0=1 means Query; clearing it requests control. Returned bit 0 is Reserved. Return bits 1, 2, and 3 indicate failure, unrecognized UUID, and unrecognized Revision; bit 4 indicates Capabilities Masked. Preserved Control bits after an error are not successful grants.

A grant does not prove every device has the capability; a zero response does not prove absent hardware. Firmware cannot deny solely because it lacks explicit feature support; it needs explicit platform incompatibility knowledge. The OS must still inspect individual Slots/Functions.

Read a complete negotiation through its dependencies

The example requests native Hot-Plug bit 0, native PME bit 2, AER bit 3, PCI Express Capability Structure bit 4, and DPC bit 7: Control=0x9D. DPC also requires Support bit 7 for Error Disconnect Recover (EDR). Support=0x9F declares bits 0–4 and 7: Extended Config operation regions, ASPM, Clock PM, Segment Groups, MSI, and EDR. LTR, Completion Timeout, and SFI control are not requested.

PME

Power Management Event

AER

Advanced Error Reporting

DPC

Downstream Port Containment

MSI

Message Signaled Interrupt

LTR

Latency Tolerance Reporting

Hot-Plug, PME, and AER require Control bit 4; DPC additionally requires Control bit 3. Firmware retaining DPC must retain AER. Granting DPC requires granting AER and Capability control. Bit 4's broad name does not override individual ownership rules. ASPM Support is not PME Control and does not replace L1.2 hardware, timing, or LTR requirements.

PME

Power Management Event

AER

Advanced Error Reporting

LTR

Latency Tolerance Reporting

Support remains 0x0000009F. The assumed platform has a known native-DPC incompatibility, no other errors, and no prior grants. 0x9D & ~0x15 = 0x88 identifies masked AER/DPC. A Query must not change hardware settings; the specification strongly recommends querying until masking clears. The second row still does not transfer ownership. The third valid response grants Hot-Plug, PME, and the applicable Capability control.

Handoff responsibilities and limited EDR exceptions

When granting Hot-Plug, firmware establishes native event routing and then stops updating slot indicators and power state. PME has corresponding routing/register restrictions. Subsequent calls within the same boot and Host Bridge must retain declared support and granted control requests; firmware cannot revoke grants. Firmware 3.3 provides no mechanism for the OS to relinquish acquired control.

Why may the OS clear some status while firmware still owns DPC?

Table 4-6 in PCI Firmware 3.3 defines specific Error Disconnect Recover (EDR) cooperation exceptions. They permit selected Status writes on particular objects during bounded intervals. AER Mask, Severity and DPC Control configuration remains with the existing owner.

Handle the triggering Port, then the downstream Function

Start with the first Control bit 7 exception in Table 4-6. From EDR Notify until the OS invokes the corresponding _OST, the OS may write Device Status and the listed AER Status registers in the triggering Port, and may handle that Port's DPC Trigger Status. Firmware must obey the specified write prohibitions during this interval. Root Error Status and RP PIO Status are also listed, but retain their Port Type and capability applicability; this example does not apply Root Port-only fields to the Switch Port.

Here, 02:01.0 has DPC base=0x300. After preserving valid evidence and observing Data Link Layer Link Active=0 in Link Status, the OS follows recovery policy and performs a 16-bit write of 0x0001 to 0x308 to clear DPC Trigger Status. The write exception does not waive Base 6.0 hardware requirements. A Root Port supporting RP Extensions must also wait for DPC RP Busy=0.

Chapter 12 demonstrated a native owner writing 0x0008 to clear DPC Interrupt Status before release. That sequence cannot simply be copied here: the limited Port exception permits DPC Trigger Status handling, not modification of DPC Interrupt Status or all of DPC Control. Establish permission before applying the field's write semantics.

On the next page of Table 4-6, the target changes. The Port's notification-processing window ends when the OS invokes _OST. Only after that _OST returns does the separate downstream Function window begin. For 03:00.0, it covers Device Status, AER Uncorrectable Error Status and Correctable Error Status until that Function is reinitialized or disabled. The specification also lists a DPC status exception where applicable; this does not imply an ordinary Endpoint implements DPC.

Firmware must honor the corresponding write prohibitions during each applicable window, preventing concurrent changes to the same status. Normal configuration ownership continues to follow _OSC; completing EDR does not automatically grant AER or DPC to the OS.

Identify the triggering Port before applying the exception

Section 4.6.13 permits EDR Notify to target an ancestor of the Port that actually experienced containment. If the notification target provides the locating _DSM, the OS must use it to find the contained Port; if absent, the notification target itself is assumed to be that Port. This example assumes identification has completed. A notification object's name alone cannot be substituted for 02:01.0.

A separate path applies while processing subsequent hot-removal below a Port whose DPC Trigger Status remains set. Table 4-6 also permits handling that Port's Trigger Status in that context. This exception does not extend to arbitrary DPC writes during normal operation.

Keep the three evidence categories separate