From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=66.187.233.73; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id DD7F320955F08 for ; Wed, 28 Feb 2018 01:33:20 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 06F1587ABA; Wed, 28 Feb 2018 09:39:27 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-11.rdu2.redhat.com [10.10.120.11]) by smtp.corp.redhat.com (Postfix) with ESMTP id A9702946A4; Wed, 28 Feb 2018 09:39:25 +0000 (UTC) To: Guo Heyi , "Ni, Ruiyu" Cc: Eric Dong , Ard Biesheuvel , edk2-devel@lists.01.org, Michael D Kinney , Star Zeng References: <1519697389-3525-1-git-send-email-heyi.guo@linaro.org> <1519697389-3525-2-git-send-email-heyi.guo@linaro.org> <563e76b9-ebbc-be09-d306-8dcb86f12112@Intel.com> <20180227093334.GA3918@SZX1000114654> <19deadb3-4d26-914c-c9f8-c6c6716746fa@Intel.com> <20180227104501.GD3918@SZX1000114654> <20180227114435.GH3918@SZX1000114654> <55c50dc9-4ce4-60a6-342c-35cd2f8d37cd@Intel.com> <17035d2f-3a5d-b3be-149d-d7179f173677@Intel.com> <20180228075348.GB27903@SZX1000114654> From: Laszlo Ersek Message-ID: <7df05a7c-1161-5c4a-7720-5c27c6fd9129@redhat.com> Date: Wed, 28 Feb 2018 10:39:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180228075348.GB27903@SZX1000114654> X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 28 Feb 2018 09:39:27 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 28 Feb 2018 09:39:27 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'lersek@redhat.com' RCPT:'' Subject: Re: [RFC v4 1/3] MdeModulePkg/PciHostBridgeDxe: Add support for address translation X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Feb 2018 09:33:22 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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