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

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, May 12, 2026 at 05:57:19PM -0600, 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,

I think there are specific already deployed distros that need to work
under qemu though - so I would discount anything that needs kernel
changes to work

Jason