On 8/31/2026 8:42 AM, Gerd Hoffmann wrote:
> Hi,
>
>>> Is this the reason we cannot rely on the Enhanced Allocation (EA)
>>> capability here?
>>
>> AFAICT, this was explored on RFC v1.
>
>> EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL was suggested as the
>> shorter path at the time, which is what this series uses.
>
> Essentially we have *two* problems to solve here. The first is how do
> we get the fixed bar information from qemu to the firmware, and the
> second is how we integrate that into edk2.
>
> So we could have a driver which parses EA and passes along the
> information found to PciDxe using
> EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL.
>
> Not sure how much of a win that would be compared to adding EA support
> to PciDxe directly given that the PciDxe bridge window logic needs
> enhancements to properly handle fixed bars (as discussed below).
Agreed, EA doesn't buy us much here; the bridge-window fix is needed
either way.
>
>>> Agreed - if the bridge windows are not programmed correctly on the first
>>> pass, there is something in the code that needs to be fixed. I don't think
>>> papering over it like this is the right approach.
>>
>> That's a fair point. I did the window-sizing after PciBusDxe because I
>> didn't want to touch existing PciBusDxe code too much.
>>
>> As per my understanding, PciBusDxe's enumeration splits into three phases:
>>
>> Phase 1 (PciHostBridgeEnumerator) walks the whole tree and calls
>> CheckDevice() per device — by the time this phase finishes, every fixed
>> BAR address is already known and cached on the device
>> (PciBar[Bar].FixedBaseAddress).
>>
>> Phase 2 (PciHostBridgeResourceAllocator) prepares an address for every
>> resource node in the tree — both individual BARs and bridge windows
>> alike — purely from size and alignment; PCI_RESOURCE_NODE has no address
>> field at all, so this is entirely blind to whether a fixed address was
>> already required.
>>
>> Phase 3 (ProgramResource) then writes the actual PCI config-space
>> registers, and by default it just writes whatever address Phase 2
>> prepared, for both BARs and bridge windows. The one exception is
>> ProgramBar() — it specifically checks whether that particular BAR was
>> marked fixed back in Phase 1, and if so, overrides Phase 2's prepared
>> base address with the real fixed one. However, ProgramPpbApperture(),
>> which writes the bridge's own window registers, has no equivalent
>> override — it always writes whatever Phase 2 prepared, with no awareness
>> of a fixed BAR anywhere underneath it. And that needs fixing, and for
>> that I have to change the existing code.
>>
>> I think the fix would be to extend Phase 2's own sizing step
>> (CalculateResourceAperture() in PciResourceSupport.c) to check for the
>> already-known fixed address on each child and, when present, size and
>> position the window as the exact union of those addresses instead of the
>> blind size-only sum. Does that match the direction you had in mind, or
>> is there a different integration point you'd suggest?
>
> Sounds about right, when propagating resource requirements up from
> devices to bridges looking only at the size is not enough if we want
> properly support pci bars at fixed locations.
Thanks for confirming the direction. I'll implement this and post it as
part of the next round.
>
> take care,
> Gerd
Thanks.
-Tushar
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#122144): https://edk2.groups.io/g/devel/message/122144
Mute This Topic: https://groups.io/mt/120952983/21656
Group Owner: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
