From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Wed, 21 Aug 2019 01:46:31 -0700 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E39BE307D853; Wed, 21 Aug 2019 08:46:30 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-79.ams2.redhat.com [10.36.117.79]) by smtp.corp.redhat.com (Postfix) with ESMTP id 24D3E2E044; Wed, 21 Aug 2019 08:46:28 +0000 (UTC) Subject: Re: [edk2-devel] [Patch] MdeModulePkg DxeCore: Fix for missing MAT update To: "Gao, Liming" , "devel@edk2.groups.io" , "Kinney, Michael D" Cc: Mike Turner , "Wang, Jian J" , "Wu, Hao A" , "Bi, Dandan" References: <20190810141022.18228-1-liming.gao@intel.com> <66665886-fff1-248a-77e5-6b8fb6966f86@redhat.com> <96f6e8a3-7049-478a-a8f2-4389c06f0e12@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E4D0EE7@SHSMSX104.ccr.corp.intel.com> <28d0e7fa-35c8-ca4b-a476-3afdd5d1c3a2@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E4D101F@SHSMSX104.ccr.corp.intel.com> <684cdd50-88d7-500e-ca56-c59f11e0e615@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E4D28C7@SHSMSX104.ccr.corp.intel.com> <5e9663fa-7f62-d510-ae4a-389554a578e8@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E4D31DA@SHSMSX104.ccr.corp.intel.com> From: "Laszlo Ersek" Message-ID: <3ab30114-ec82-aaec-cd8a-016c351012e4@redhat.com> Date: Wed, 21 Aug 2019 10:46:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E4D31DA@SHSMSX104.ccr.corp.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.48]); Wed, 21 Aug 2019 08:46:31 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Hi Liming, On 08/19/19 02:40, Gao, Liming wrote: >> ... Ugh, wait. I've actually implemented this for OVMF almost 2 years >> ago! And the answer to my question is "yes": >> >> https://bugzilla.tianocore.org/show_bug.cgi?id=386 >> https://lists.01.org/pipermail/edk2-devel/2017-November/018312.html >> >> See the OnReadOnlyVariable2Available() function: >> >> + // >> + // Check if the "MemoryTypeInformation" variable exists, in the >> + // gEfiMemoryTypeInformationGuid namespace. >> + // >> + ReadOnlyVariable2 = Ppi; >> + DataSize = 0; >> + Status = ReadOnlyVariable2->GetVariable ( >> + ReadOnlyVariable2, >> + EFI_MEMORY_TYPE_INFORMATION_VARIABLE_NAME, >> + &gEfiMemoryTypeInformationGuid, >> + NULL, >> + &DataSize, >> + NULL >> + ); >> + if (Status == EFI_BUFFER_TOO_SMALL) { >> + // >> + // The variable exists; the DXE IPL PEIM will build the HOB from it. >> + // >> + return EFI_SUCCESS; >> + } >> + // >> + // Install the default memory type information HOB. >> + // >> + BuildMemTypeInfoHob (); >> >> Apologies for forgetting about this; you are right. >> >> Too bad my work for TianoCore#386 was rejected. :( >> > > So, this is one value to add PEI variable support in OVMF. > Do you consider to approve this feature request? Sorry, I don't understand your question. Are you asking me if, in my opinion, we should fix TianoCore#386 (= add PEI variable support to OVMF)? If that is your question, then my answer is -- trivially -- "yes". If you read through TianoCore#386, you will see that I submitted patches for solving the BZ, twice (comment 6, comment 9). Jordan rejected my patches both times, because he thought that the same feature should be implemented in OVMF for Xen as well. I disagreed (and still disagree) -- my patches depend on a build-time flag that produces an OVMF binary that is only compatible with QEMU, and not Xen. The reason for that is that the feature (PEI variable support) cannot be implemented *sensibly* on Xen. (Xen offers no spec-conformant variable storage, and in the PEI phase, the variable store would always appear empty.) Later, Jordan tried to add dynamic pflash detection to PEI, but it didn't work in all cases, because OVMF's PEI phase doesn't run in SMM, while QEMU restricts pflash access to SMM. (In other words, pflash protection in QEMU is less flexible than SMRAM protection -- SMRAM is unlocked in PEI, but pflash is always locked.) Please see the threads linked in the BZ for the discussion. With TianoCore#1689, Anthony has started separating OVMF into different firmware platforms for Xen and QEMU. In a year or so, "OVMF for QEMU" will likely have nothing Xen-related in it (because "OVMF for Xen" will exist separately). Then we can reopen TianoCore#386 just for "OVMF for QEMU", and solve this feature. In summary, I have had patches for TianoCore#386 ready for 2+ years, they've been blocked because they only target QEMU (with a build-time flag), and I expect to upstream them finally as soon as OvmfPkg offers dedicated firmware platforms for Xen and QEMU separately. Thanks Laszlo