From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org 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 DD267211B1138 for ; Mon, 7 Jan 2019 07:28:07 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A4BD289AC8; Mon, 7 Jan 2019 15:28:06 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-125-185.rdu2.redhat.com [10.10.125.185]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2F87227BC1; Mon, 7 Jan 2019 15:28:03 +0000 (UTC) To: Ard Biesheuvel Cc: Jagadeesh Ujja , "Gao, Liming" , "Kinney, Michael D" , "edk2-devel@lists.01.org" , "Zhang, Chao B" , Leif Lindholm , Achin Gupta , Supreeth Venkatesh , Jian J Wang References: <1546434828-24405-1-git-send-email-jagadeesh.ujja@arm.com> <1546434828-24405-5-git-send-email-jagadeesh.ujja@arm.com> <8a6e1c80-5b6e-e337-06af-5992bc38a844@redhat.com> From: Laszlo Ersek Message-ID: Date: Mon, 7 Jan 2019 16:28:03 +0100 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: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 07 Jan 2019 15:28:06 +0000 (UTC) Subject: Re: [PATCH v2 04/11] MdePkg/Include: Add StandaloneMmServicesTableLib library X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 15:28:08 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 01/04/19 12:57, Ard Biesheuvel wrote: > On Thu, 3 Jan 2019 at 17:14, Laszlo Ersek wrote: >> >> On 01/03/19 12:03, Ard Biesheuvel wrote: >>> On Wed, 2 Jan 2019 at 14:14, Jagadeesh Ujja wrote: >>>> >>>> Some of the existing DXE drivers can be refactored to execute within >>>> the Standalone MM execution environment as well. Allow such drivers to >>>> get access to the Standalone MM services tables. >>>> >>>> Add a mechanism to determine the execution mode is required. >>>> i.e, in MM or non-MM >>>> >>>> Contributed-under: TianoCore Contribution Agreement 1.1 >>>> Signed-off-by: Jagadeesh Ujja >>>> --- >>>> MdePkg/Include/Library/StandaloneMmServicesTableLib.h | 43 ++++++++++++++++++++ >>>> MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.c | 39 ++++++++++++++++++ >>>> MdePkg/Library/StandaloneMmServicesTableLib/StandaloneMmServicesTableLib.inf | 36 ++++++++++++++++ >>>> MdePkg/MdePkg.dec | 4 ++ >>>> 4 files changed, 122 insertions(+) >>>> >>> >>> OK, so since the PI spec only refers to MM mode now, this library >>> class should be >>> >>> MmServicesTableLib|Include/Library/MmServicesTableLib.h >>> >>> with an implementation in MdeModulePkg that exposes the deprecated SMM >>> system table as the MM system table. >>> >>> In StandaloneMmPkg, we can add an implementation that exposes the >>> standalone MM system table. >>> >>> (They are binary compatible, so it is just a matter of casting one >>> pointer to the other) >>> >>> With this in place, we can go ahead and update FaultTolerantWrite and >>> Variable SMM driver to switch from SmmServicesTableLib to >>> MmServicesTableLib. This will require existing x86 platforms to define >>> a new library class resolution for MmServicesTableLib, referring to >>> the implementation in MdeModulePkg. This is unfortunate, but it is an >>> unavoidable consequence of the PI spec changes. >> >> It shouldn't be too intrusive or hard to review, I expect. >> >>> >>> Remaining question is what to do with InSmm() ... >> >> I'm lacking the context on this; on the other hand, I can refer back to >> at least one earlier discussion -- there had been multiple -- of the >> discrepancy between the PI spec and the edk2 code. See: >> >> - bullet (9) in >> , >> - and >> . >> >> Not sure how that can be applied to Arm. >> > > The code I posted yesterday does not use InMm() at all. For standalone > MM, it should always return TRUE anyway, and any code that a driver > would execute if it returned FALSE needs to be factored out anyway, > since it should not end up in standalone MM binaries as dead code. > OK. That seems to make sense. I've read up a bit on "standalone MM" in the PI v1.6 spec, vol 4. Having no access to UEFI protocols even in the entry point function, at driver init time, seems challenging to me. I guess I'll learn more about this as a part of the usual list traffic. What is the MODULE_TYPE that standalone MM drivers use, in place of DXE_SMM_DRIVER (= EFI_FV_FILETYPE_MM, 0x0A)? Hm... from the other patches, it seems to be MM_STANDALONE (= EFI_FV_FILETYPE_MM_STANDALONE, 0x0E). OK. If I'd like to see a short summary of standalone MM, relative to traditional MM, and why it is more suitable -- I presume -- for aarch64, which document should I look at, from , for example? Thanks! Laszlo