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 9556621A07AB5 for ; Thu, 22 Jun 2017 09:21:09 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2F6F730AF6D; Thu, 22 Jun 2017 16:22:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2F6F730AF6D Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2F6F730AF6D Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-27.phx2.redhat.com [10.3.116.27]) by smtp.corp.redhat.com (Postfix) with ESMTP id F153E61F4C; Thu, 22 Jun 2017 16:22:32 +0000 (UTC) To: "Yao, Jiewen" , "Justen, Jordan L" References: <20170608171333.17937-1-lersek@redhat.com> <20170608171333.17937-2-lersek@redhat.com> <149789342556.32751.17592475673245441129@jljusten-skl> <74D8A39837DF1E4DA445A8C0B3885C503A96B991@shsmsx102.ccr.corp.intel.com> From: Laszlo Ersek Cc: "Fan, Jeff" , "Kinney, Michael D" , edk2-devel-01 Message-ID: Date: Thu, 22 Jun 2017 18:22:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <74D8A39837DF1E4DA445A8C0B3885C503A96B991@shsmsx102.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Thu, 22 Jun 2017 16:22:34 +0000 (UTC) Subject: Re: [PATCH 1/5] OvmfPkg: introduce Q35TsegSizeLib (class header and sole lib instance) X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 16:21:09 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 06/21/17 02:52, Yao, Jiewen wrote: > As far as I know, the real platform SmmAccessPeim may depend on > gEfiPeiMemoryDiscoveredPpiGuid, because the SmramHob is produced in > MRC wrapper. Thanks for the info, Jiewen! - I don't know what "MRC wrapper" is. I found "QuarkPlatformPkg/Platform/Pei/PlatformInit/MrcWrapper.c", with the comment "Framework PEIM to initialize memory on a Quark Memory Controller". - I don't know what "SmramHob" is. I see some hits in QuarkPlatformPkg and Vlv2TbltDevicePkg. The type seems to be "EFI_SMRAM_HOB_DESCRIPTOR_BLOCK", in "IntelFrameworkPkg/Include/Guid/SmramMemoryReserve.h", with the comment "GUID specific data structure of HOB for reserving SMRAM regions". I think the comment is inaccurate. From the data structure itself, it looks like the HOB is used to expose the possible SMRAM regions to "other" modules, and not to reserve regions from SMRAM. Anyway, I guess the HOB is consumed by modules such as: - QuarkSocPkg/QuarkNorthCluster/Smm/Dxe/SmmAccessDxe - QuarkSocPkg/QuarkNorthCluster/Smm/Pei/SmmAccessPei So apparently, on Quark, the PEIM that initializes physical RAM produces the SmramHob (which is an Intel Framework concept, apparently), and SmmAccessPei consumes the SmramHob. In order to serialize these operations, the two PEIMs reuse / repurpose gEfiPeiMemoryDiscoveredPpiGuid, as a PEIM dispatch barrier. The availability of SmramHob is parallel to the availability of gEfiPeiMemoryDiscoveredPpiGuid. This doesn't match OVMF for two reasons: - In OVMF / on QEMU, we don't initialize RAM (we don't have to). - In OVMF, we have a separate SmmAccessPei implementation, which does not rely on such a HOB. Rebasing the SMM platform code in OVMF to SmramHob is out of scope, in my opinion. The current layout of drivers works fine; we just need a new bit pattern (11 binary) in the ESMRAMC.TSEG_SZ bitfield, and OVMF should be able to query QEMU as to what that bit pattern translates to, size-wise. That's all. > At same time, I also saw a solution to use library to produce > SmmAccessPpi. In such case, there is no dependency expression, because > one module does 2 things: 1) init memory, 2) produce SmmAccessPpi. I agree that this is a technical possiblity, but for OVMF it is again out of scope. One reason is separation of concepts. Another reason is that OVMF can be built without SMM support (that's the default actually), and for such a build the library approach would require a Null instance of whatever new library class we would invent. Too much churn. Jordan, can we please go ahead with the posted approach? If you strongly prefer dynamic PCDs (which I *slightly* dislike), I can do that -- hacking a spurious gEfiPeiMemoryDiscoveredPpiGuid dependency into SmmAccessPei.inf, as a serialization barrier between PCD setting and PCD consumption --, for the sake of making progress on this series. Thanks, Laszlo