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

["Gerd Hoffmann" <kraxel@redhat.com>]

On Mon, May 23, 2022 at 04:48:05AM -0700, Albecki, Mateusz wrote:
> @Ni, Ray
> 
> I think EDK2 needs to provide a way for root port to operate without IO space assigned in a platform-independent way. I can think of the following cases when root port didn't get IO space:
> 
> 1. We have run out of IO space but it's fine since the device under the root port doesn't use IO or has only non-critical functionalities under IO
> 2. We have run out of IO space and it's really not fine since device needs IO
> 3. We are running on a CPU which doesn't support IO
> 
> For 1. the question is whether the device driver in EDK2 understands that IO bar for that device is optional and will bother to check if it has been assigned and either fail gracefully or continue operation in limited capacity. For 2. the question is whether the driver will fail gracefully. 3 is for completeness at this point I think since the only other architecture that uses EDK2 is ARM which has to deal with it in some way right now which I think maps IO region into MMIO so in a way it supports IO.

Well, the case I'm trying to handle here is qemu microvm.  It's x86, but
io address space support for pcie devices is not wired up.   So the pcie
host bridge doesn't support io, which is rather close to case (3).

> I've checked the device driver behavior in EDK2 for devices which use IO bar here is the rundown:
> 1. IDE - Doesn't check if IO has been assigned, not giving IO results in undefined behavior
> 2. SerialIo -> Doesn't check, will assert the system when IO is not assigned (although the logic there is really strange as it can use 3 different access methods)
> 3. UHCI -> Checks but too late, will most likely result in undefined behavior

Current edk2 behavior is that the initialization of the pcie host bridge
fails in case no io space is present (and all devices connected to it are
not initialized either of course).

With this patch applied pcie host bridge initialization works.  PCIe
devices without io bars are enumerated and initialized sucessfully.
PCIe devices with io bar fail to initialize.  That isn't much of a
problem tough as a qemu microvm typically has no pcie devices with io
bars.

> Even with those bad device drivers I would agree that taking this
> change presents low risk given that those devices are pretty old and
> should be mostly unused on new systems(SerialIo being an exception but
> that one is usually an RCIEP).

Also note that for pcie root bridges which do support io address space
this patch changes nothing.

> That said I think we are missing a larger issue here - why are we
> running out of IO when we have 16 root ports?

I don't think so.  I see the *linux kernel* hand out io address space to
pcie root ports (until it runs out).  edk2 doesn't.

take care,
  Gerd