From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 9A3071A1EFA for ; Thu, 15 Sep 2016 08:48:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1473954513; x=2337868113; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=bOilSUVkCx3lubMymCMzReoIRa8gD74UlTB0ZHA+dpw=; b=uLvL2iFcxJJ8VXn6IiBDhx2gseRLI2Vyguc+807kt+WuhD+zKV0Bz/HL/cVwvxpG geKQNSkne+Vd0/WvMBPBgNB/bIfu8s/1SrPDefFFXnaHJ3quFWnfmPJJygvYs7SA F9ZSOSgWDbh/i2fUZVZe7ExsHtXyH9vTk2bAjtVcx4S9N7C0oWudrg5tqQMMOTyY CNpQD8+l6LjZ6YIC0K/hG7VF9utkvfYLEtR4Er/83KFDlmC30RH2b2Mydl7THpqo WMRA/e34kQQBMOv16DqMfQgy8rGHsugln4sxI6Jl/UxXiao5WEP6GSPF9IvqHnRv bjVlDK041LlUQG7ti5RLJQ==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id EC.4C.07752.1D2CAD75; Thu, 15 Sep 2016 08:48:33 -0700 (PDT) X-AuditID: 11973e15-f798f6d000001e48-ce-57dac2d1fa88 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay4.apple.com (Apple SCV relay) with SMTP id 76.5C.20305.1D2CAD75; Thu, 15 Sep 2016 08:48:33 -0700 (PDT) MIME-version: 1.0 Received: from [17.153.16.164] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0ODJ009J1YKXER30@nwk-mmpp-sz10.apple.com>; Thu, 15 Sep 2016 08:48:33 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish In-reply-to: <20160915152831.GH16080@bivouac.eciton.net> Date: Thu, 15 Sep 2016 08:48:33 -0700 Cc: Ard Biesheuvel , ruiyu.ni@intel.com, feng.tian@intel.com, edk2-devel@lists.01.org, liming.gao@intel.com, jiewen.yao@intel.com, Mike Kinney , lersek@redhat.com, star.zeng@intel.com Message-id: <9892B892-284A-40F8-953C-C7830A0C7C55@apple.com> References: <1473951296-19120-1-git-send-email-ard.biesheuvel@linaro.org> <20160915152831.GH16080@bivouac.eciton.net> To: Leif Lindholm X-Mailer: Apple Mail (2.3112) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUi2FAYrnvx0K1wg4fXzCz+f9jNaLHn0FFm i0m72S3WffSw+LR7D4vFsmM7WCxW3NvAbtHR8Y/J4mXPanaLfb3WDlwei/e8ZPK4c20Pm0f3 7H8sHu/3XWULYInisklJzcksSy3St0vgyji/t5+p4Lt0xce3O5kaGE+KdTFyckgImEh8unaY EcIWk7hwbz1bFyMXh5DAXkaJ028/s8AUHdg8hQkicYhRYu+GS0wgCV4BQYkfk+8BFXFwMAvI Sxw8LwsSZhbQkvj+qJUFov4do8S532fA6oUFxCXendnEDGHHSiyZ9AUsziagLLFi/gd2EJtT wELi/IO1YHEWAVWJdb17wQYxC3xhlJj58jsbxGIbif0b54MVCQmUS3yd8RfsUhEBHYnTX/8x Q1wtK7FvwwI2CPs7m0TDjZwJjCKzkNw9C+HuWUjuXsDIvIpRKDcxM0c3M89ML7GgICdVLzk/ dxMjKKKm24nuYDyzyuoQowAHoxIP74q5t8KFWBPLiitzDzFKc7AoifPGv70RLiSQnliSmp2a WpBaFF9UmpNafIiRiYNTqoFRfcqGmGXzft7VyMs8tuR8ZNMHR8O/VVf8VecGryi/1fH76IM5 M7arWWutNCxqbSxW3+Brq3H6WVTAr21rOt45zH78bPfUXE6jWQ/T1nRdV/++a8HJCvUZc4N9 LPz4Df/rHNNedFT31upPdr/yjjm83fTYJCXbfvOEX/fnzn25Vd5Sbk6ZyqR50UosxRmJhlrM RcWJAGl8EgyJAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEIsWRmVeSWpSXmKPExsUi2FBcpXvx0K1wg+eXDS3+f9jNaLHn0FFm i0m72S3WffSw+LR7D4vFsmM7WCxW3NvAbtHR8Y/J4mXPanaLfb3WDlwei/e8ZPK4c20Pm0f3 7H8sHu/3XWULYInisklJzcksSy3St0vgyji/t5+p4Lt0xce3O5kaGE+KdTFyckgImEgc2DyF CcIWk7hwbz1bFyMXh5DAIUaJvRsugSV4BQQlfky+x9LFyMHBLCAvcfC8LEiYWUBL4vujVhaI +neMEud+nwGrFxYQl3h3ZhMzhB0rsWTSF7A4m4CyxIr5H9hBbE4BC4nzD9aCxVkEVCXW9e4F G8Qs8IVRYubL72wQi20k9m+cD1YkJFAu8XXGXxYQW0RAR+L013/MEFfLSuzbsIBtAqPgLCS3 zkK4dRaSWxcwMq9iFChKzUmsNNFLLCjISdVLzs/dxAiOgcLwHYz/llkdYhTgYFTi4V0591a4 EGtiWXFlLjAwOJiVRHgl9wGFeFMSK6tSi/Lji0pzUosPMSYDPTCRWUo0OR8Yn3kl8YYmJgYm xsZmxsbmJuakCSuJ80qpXQ8XEkhPLEnNTk0tSC2C2cLEwSnVwCitu8ol//gfNTWlBp03V1r4 igL2vQpRdzH/syox89AZjuU9sZ5LNOUPJjbZXjnA2HzSRNNt5cqylo47tVXCwsrcdnZbe+Zu Wicvcfjkipw4ho8GftM4TrbKWoVeOChbUyUXISOzcIrAnTlFMue4Q33nnb/UWfov0//MtY+G 56N8s7c5yx79osRSnJFoqMVcVJwIAHRC6LfFAgAA Subject: Re: [PATCH] MdeModulePkg/PciBusDxe: make OPROM BAR degradation X64 specific X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2016 15:48:34 -0000 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII > On Sep 15, 2016, at 8:28 AM, Leif Lindholm wrote: > > On Thu, Sep 15, 2016 at 03:54:56PM +0100, Ard Biesheuvel wrote: >> The 'universal' PCI bus driver in MdeModulePkg contains a quirk to >> degrade 64-bit PCI MMIO BARs to 32-bit in the presence of an option >> ROM on the same PCI controller. >> >> This quirk is highly specific to not just the X64 architecture in general, >> but to the PC platform in particular, given that only X64 platforms that >> require legacy PC BIOS compatibility require it. However, making the >> quirk dependent on the presence of the legacy BIOS protocol met with >> resistance, due to the fact that it introduces a dependency on the >> IntelFrameworkModulePkg package. >> >> So instead, make the quirk dependent on whether we are compiling for the >> X64 architecture, by putting the #ifdef MDE_CPU_X64/#endif preprocessor >> directives around it. >> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Ard Biesheuvel > > I'm happy with the change, but it may be worth putting a comment in Do we have to use an #ifdef? Seems like it should be a PCD. Is this for legacy BIOS Option ROM support, or for existing EFI ROMs? Thanks, Andrew Fish > the code to the extent that: > --- > In order to reliably support legacy Option ROMs, which may not be > 64-bit safe, X64 needs to ensure PCI MMIO BARs are forced down to use > only the lower 32 bits. > Other architectures, or indeed X64 without legacy option ROM support, > can safely leave these in normal operation mode (and may require so in > order to function). > --- > > For what it's worth: > Reviewed-by: Leif Lindholm > >> --- >> >> Since nobody proposed any alternatives to the solution I proposed, >> let's just make the quirk disappear on architectures that have no >> use for it. >> >> Note that forcing non-X64 architectures to install a driver that >> produces the IncompatiblePciDevice protocol only to make the PCI >> bus driver behave normally (and which, incidentally, can only be >> produced once per platform, making it difficult to provide a default >> implementation that can be widely reused) is not acceptable IMO. >> >> If anything, this should require an IncompatiblePlatform protocol >> that informs the PCI bus driver that a special quirk is required, >> but I am aware that this is difficult to accomplish without breaking >> backward compatibility. Hence this compromise. >> >> MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c >> index b0632d53b82b..b4771a822d65 100644 >> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c >> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c >> @@ -1052,6 +1052,7 @@ DegradeResource ( >> IN PCI_RESOURCE_NODE *PMem64Node >> ) >> { >> +#ifdef MDE_CPU_X64 >> PCI_IO_DEVICE *PciIoDevice; >> LIST_ENTRY *ChildDeviceLink; >> LIST_ENTRY *ChildNodeLink; >> @@ -1101,6 +1102,7 @@ DegradeResource ( >> } >> ChildDeviceLink = ChildDeviceLink->ForwardLink; >> } >> +#endif >> >> // >> // If firmware is in 32-bit mode, >> -- >> 2.7.4 >> > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel