Re: [edk2-devel] [RFC PATCH 0/8] hw/arm/virt, hw/pci: PCI pre-enumeration and fixed BAR allocation

["Ard Biesheuvel" <ardb@kernel.org>]

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.