Re: [RFC v4 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation

[Laszlo Ersek <lersek@redhat.com>]

On 02/28/18 08:53, Guo Heyi wrote:
> On Wed, Feb 28, 2018 at 03:25:03PM +0800, Ni, Ruiyu wrote:

>> Heyi,
>> My understanding is this whole change is backward compatible.
>> Which means an old version of PciHostBridgeLib + new PciHostBridgeLib.h +
>> new PciHostBridgeDxe driver won't cause build failure.
>> right?
> 
> Not really; as Laszlo indicated in one mail, some implementations of
> PciHostBridgeLib uses temporary PCI_ROOT_BRIDGE_APERTURE variables and only
> initialize Base and Limit fields of the variables, like the code in
> https://github.com/tianocore/edk2/blob/master/CorebootPayloadPkg/Library/PciHostBridgeLib/PciHostBridgeSupport.c#L315
> and
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.c#L216
> and
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/PciHostBridgeLib/XenSupport.c#L189

Right -- while Ray is asking whether this change can cause a build
failure (and no, it can't), it is true that some PciHostBridgeLib
instances don't fully clear some structures that "PciHostBridgeLib.h"
defines (only member-wise assignments exist). So client code has to be
patched up for functionality, not for build errors.

> I'm also preparing the patches for these PciHostBridgeLib instances in edk2
> tree, which are expected to be committed after PciHostBridgeLib.h change and
> before PciHostBridge driver change.

That's a great idea; it should help with bisectability.

In fact, you could submit those patches first (even independently); I
think they'd mostly just insert a few well-placed ZeroMem() calls. One
could argue that they should have been added right from the start (we
expected the "PciHostBridgeLib.h" structures to expand over time, just
missed a few init spots for them).

Thanks,
Laszlo