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 4BD4E1A1E01 for ; Tue, 30 Aug 2016 06:45:40 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 9F7E88B135; Tue, 30 Aug 2016 13:45:39 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-135.phx2.redhat.com [10.3.116.135]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7UDjbvJ028197; Tue, 30 Aug 2016 09:45:38 -0400 To: "Fan, Jeff" , "Zeng, Star" , "edk2-devel@ml01.01.org" References: <1470128388-17960-1-git-send-email-jeff.fan@intel.com> <1470128388-17960-49-git-send-email-jeff.fan@intel.com> <4f61b2b4-eeb4-8435-412f-20848347c88e@redhat.com> <542CF652F8836A4AB8DBFAAD40ED192A143D9CFD@shsmsx102.ccr.corp.intel.com> <795dd4fe-cd16-c0f1-7f04-f78601e2c7a8@redhat.com> <82c6b5c9-dcab-f3c1-5ffe-20fb27ddb1af@intel.com> <6cd44902-8c07-8f76-1204-d79c85559ae5@intel.com> <7d39ce29-88ce-c5f2-af61-7fd964acb5c0@intel.com> <801f810c-4cd7-d657-f536-a8471a37802c@redhat.com> <8c9e77d3-14d2-4a92-2407-eb80cd255bb4@intel.com> <542CF652F8836A4AB8DBFAAD40ED192A143DEF4E@shsmsx102.ccr.corp.intel.com> Cc: "Kinney, Michael D" , "Justen, Jordan L" , "Tian, Feng" From: Laszlo Ersek Message-ID: <8373cabb-8bf5-bb9e-2377-e7b045b54c59@redhat.com> Date: Tue, 30 Aug 2016 15:45:37 +0200 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: <542CF652F8836A4AB8DBFAAD40ED192A143DEF4E@shsmsx102.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 30 Aug 2016 13:45:39 +0000 (UTC) Subject: Re: [Patch v5 48/48] UefiCpuPkg/PiSmmCpuDxeSmm: Add gEfiVariableArchProtocolGuid dependency 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: Tue, 30 Aug 2016 13:45:40 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 08/25/16 10:00, Fan, Jeff wrote: > Laszlo, > > After discussed with Star, I understood OVMF's circle dependency on Variable Arch protocol and SMM CPU driver. > > I will defer to check-in this patch till found the better solution. Thank you! > Before the proper fix adopted, our platforms might not set the HII types dynamic PCDs used by PiSmmCpuDxeSmm driver. If I understand correctly, such dynamic PCDs are stored in UEFI variables, which are in turn exposed via HII (forms). Based on "MdeModulePkg/Universal/PCD/Dxe/Pcd.inf", point 2.3 (b). It seems to me that "Default Storage" vs. "Variable Storage" is only separated in the platform DSC file; the declaration for the dynamic PCDs in question should be identical in the package DEC file. So maybe PiSmmCpuDxeSmm should only read the new dynamic PCDs, and if those are expected to come from UEFI variables, then the platform could plug a NULL library instance into PiSmmCpuDxeSmm that "imbued" PiSmmCpuDxeSmm with a depex on gEfiVariableArchProtocolGuid. Alternatively, maybe SmmCpuPlatformHookLib could be extended with a new function (or functions) for querying these dynamic settings. OvmfPkg could provide a library instance that returned constant defaults (or even dynamic PCDs, but without variable access). And UefiCpuPkg could provide a library instance with variable-backed PCDs, plus the depex. Thanks! Laszlo