From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 2B6F21A1E21 for ; Tue, 23 Aug 2016 19:26:03 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 65DD937E63; Wed, 24 Aug 2016 02:26:02 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-2.phx2.redhat.com [10.3.116.2]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7O2Q1QY027423; Tue, 23 Aug 2016 22:26:01 -0400 To: Star Zeng , Michael D Kinney References: <1471592131-143456-1-git-send-email-star.zeng@intel.com> Cc: edk2-devel@ml01.01.org, Chan Amy , Chao Zhang , Jiewen Yao , David Wei From: Laszlo Ersek Message-ID: <7ec1654a-55c8-26bc-5340-85d10907b0e1@redhat.com> Date: Tue, 23 Aug 2016 22:26:00 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1471592131-143456-1-git-send-email-star.zeng@intel.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 24 Aug 2016 02:26:02 +0000 (UTC) Subject: Re: [PATCH 0/6] PiDxeS3BootScriptLib: Support multiple PCI segment 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: Wed, 24 Aug 2016 02:26:03 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 08/19/16 03:35, Star Zeng wrote: > Support multiple PCI segment for PCI_CONFIG2 opcodes. > > PiDxeS3BootScriptLib needs to be updated to consume PciSegmentLib > instead of PciLib. That means platforms need to add PciSegmentLib > declaration like below in platform dsc if the PciSegmentLib was > not declared in platform dsc before. > > PciSegmentLib|MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf > > For platforms only have one segment, > MdePkg/Library/BasePciSegmentLibPci/BasePciSegmentLibPci.inf is recommended > to be used and declared in platform dsc for PiDxeS3BootScriptLib to have > equivalent functionality with before. > > Cc: Jiewen Yao > Cc: Michael D Kinney > Cc: Chan Amy > Cc: Laszlo Ersek > Cc: Kelly Steele > Cc: David Wei > Cc: Chao Zhang > > Star Zeng (6): > MdeModulePkg PiDxeS3BootScriptLib: Remove the trailing white spaces > MdeModulePkg PiDxeS3BootScriptLib: Support multiple PCI segment > Vlv2TbltDevicePkg: Declare PciSegmentLib in platform dsc > QuarkPlatformPkg: Declare PciSegmentLib in platform dsc > QuarkSocPkg/QuarkSocPkg.dsc: Declare PciSegmentLib > SecurityPkg/SecurityPkg.dsc: Declare PciSegmentLib > > .../PiDxeS3BootScriptLib/BootScriptExecute.c | 411 +++++++++---------- > .../BootScriptInternalFormat.h | 2 +- > .../Library/PiDxeS3BootScriptLib/BootScriptSave.c | 451 ++++++++++----------- > .../PiDxeS3BootScriptLib/DxeS3BootScriptLib.inf | 4 +- > .../PiDxeS3BootScriptLib/DxeS3BootScriptLib.uni | 2 +- > .../PiDxeS3BootScriptLib/InternalBootScriptLib.h | 26 +- > QuarkPlatformPkg/Quark.dsc | 1 + > QuarkPlatformPkg/QuarkMin.dsc | 1 + > QuarkSocPkg/QuarkSocPkg.dsc | 1 + > SecurityPkg/SecurityPkg.dsc | 1 + > Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 1 + > Vlv2TbltDevicePkg/PlatformPkgIA32.dsc | 1 + > Vlv2TbltDevicePkg/PlatformPkgX64.dsc | 1 + > 13 files changed, 450 insertions(+), 453 deletions(-) > For patches #1 and #2: Tested-by: Laszlo Ersek (Also compared some logs.) I read the sub-thread under #2, but I don't understand Mike's concern. I can be wrong of course, but in my understanding, the boot script's internal representation does not change. The "saver" side only relaxes the Segment=0 requirement. And, the "executor side" accommodates nonzero segments in the Pci2 opcodes, and rebases the Pci[1] opcode functions on top of Pci2 opcode functions (with hardcoded Segment=0). I don't understand why calling PciSegmentLib functions with a UINT64 parameter where the segment bit-field is hardcoded to 0 is worse than calling PciLib (uncapable of nonzero segments) with an UINTN parameter. Is this about the cost of a function call on Ia32? That is, assuming a very long S3 boot script, the patch might noticeably slow down S3 resume on Ia32? Thanks Laszlo