Re: [edk2-devel] [PATCH v5 1/6] MdeModulePkg/PciHostBridge: io range is not mandatory

["Ni, Ray" <ray.ni@intel.com>]

> -----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@redhat.com>
> Cc: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; Pawel Polawski <ppolawsk@redhat.com>; Ard Biesheuvel
> <ardb+tianocore@kernel.org>; Gao, Liming <gaoliming@byosoft.com.cn>; Wu, Hao A <hao.a.wu@intel.com>; Oliver Steffen
> <osteffen@redhat.com>; Leif Lindholm <quic_llindhol@quicinc.com>; Justen, Jordan L <jordan.l.justen@intel.com>; Yao,
> Jiewen <jiewen.yao@intel.com>; Chang, Abner <abner.chang@hpe.com>; Wang, Jian J <jian.j.wang@intel.com>
> 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@redhat.com> 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.