-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Ard Biesheuvel
Sent: Friday, April 29, 2022 3:00 PM
To: Gerd Hoffmann <kraxel@...>
Cc: Ni, Ray <ray.ni@...>; devel@edk2.groups.io; Pawel Polawski <ppolawsk@...>; Ard Biesheuvel
<ardb+tianocore@...>; Gao, Liming <gaoliming@...>; Wu, Hao A <hao.a.wu@...>; Oliver Steffen
<osteffen@...>; Leif Lindholm <quic_llindhol@...>; Justen, Jordan L <jordan.l.justen@...>; Yao,
Jiewen <jiewen.yao@...>; Chang, Abner <abner.chang@...>; Wang, Jian J <jian.j.wang@...>
Subject: Re: [edk2-devel] [PATCH v5 1/6] MdeModulePkg/PciHostBridge: io range is not mandatory

On Fri, 29 Apr 2022 at 08:50, Gerd Hoffmann <kraxel@...> wrote:

On Wed, Apr 27, 2022 at 03:08:50AM +0000, Ni, Ray wrote:

Ard,
can you explain more?

Your code changes the PciHostBridge driver to ignore the failure of IO allocation.
If IO requirement of certain PCI(E) devices can be ignored, can you change the IncompatiblePciDevice protocol

implementation to override the IO request from the devices?

Hmm, it's a problem indeed, device initialization fails in case an
io bar is present even if the bar is not required to drive the device.

I'd say the risk for regressions is rather low, though, given that it
only affects configurations that would fail PCI resource allocation
today. Or am I missing something?

In any case, the PCIe spec is clear about this: I/O space is optional,
and we need to incorporate this into the generic code at *some* point.
It makes no sense for every individual platform to keep adding these
hacks.

Do you know how Linux handles this?
Can Linux allocate resource for PCI(E) devices? How does it deal with the IO type?

Suggestions how to deal with this best? ovmf has it's own
IncompatiblePciDevice Protocol implementation, so I could
handle it there because only OvmfPkg/Microvm needs this.

Or should the MdeModulePkg version be updated too?

I'd say we do both, to avoid stalling your series forever :-)

Why changing the MdeModulePkg's IncompatiblePciDevice driver can avoid
stalling the patch series?
I feel it's enough to just change the OvmfPkg version.