On 5/13/2026 9:25 AM, Ard Biesheuvel wrote:
>
> On Wed, 13 May 2026, at 01:57, Alex Williamson wrote:
>> On Tue, May 12, 2026, at 5:12 PM, Michael S. Tsirkin wrote:
>>> On Tue, May 12, 2026 at 05:06:50PM -0600, Alex Williamson wrote:
>>>> If we agree that homogeneous hierarchies (no mixing of EA and
>>>> programmable BARs) is a reasonable constraint, and possibly extend
>>>> that to homogeneous per host bridge to simplify the CRS mapping, we
>>>> have the following work items:
>>>>
>>>> * Extend Linux EA support to program bridge apertures for
>>>> subordinate homogeneous EA hierarchies.
>>>>
>>>> * Develop options to virtualize programmable BARs as EA for vfio-
>>>> pci devices, if not generically for the benefit of testing.
>>>>
>>>> * Implement a way to poke holes in the VM address space and plumb
>>>> through to account for addresses used by EA devices.
>>>>
>>>> * Provide those same ranges to the guest via CRS (but not via DT to
>>>> EDK2), or alternatively expose them through additional PXB host
>>>> bridges.
>>>>
>>>> Does that shape roughly seem accurate? Are there additional gaps
>>>> I've missed? Thanks,
>>>
>>> just one question why not do it in firmware so windows is thinkably
>>> also handled?
>>
>> I suppose someone could chime in if they have a similar requirement
>> for Windows guests. Otherwise, the incremental effort to extend Linux
>> EA support seems smaller, though I also don't know what, if any
>> support Windows has for EA to bother. Regardless, improving Linux EA
>> support might help elsewhere and doesn't preclude edk2 support in the
>> future. Thanks,
>>
>
> If EA is too much of a hassle to implement, another avenue that you
> might explore is EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL in edk2,
> which can be implemented by the platform to inform the PCI core about
> non-PCI compliant devices that have special requirements.
>
> While it is supposed to support this use case too, the PCI resource
> allocation code in EDK2 currently does not correctly support fixed
> resources that are reported by this protocol, but getting that fixed
> (and implementing the protocol in your firmware) might be a shorter
> path to getting this hardware supported under any OS (assuming EFI
> boot) than EA.
Thanks for all the input.
It seems that EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL
is the path forward to explore for this design. At a
surface level, this looks feasible, and I'll spend some
time researching it and putting together a PoC before
coming back with more details.
-Tushar
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#121968): https://edk2.groups.io/g/devel/message/121968
Mute This Topic: https://groups.io/mt/119221703/21656
Group Owner: [email protected]
Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
