From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=2607:f8b0:4864:20::d44; helo=mail-io1-xd44.google.com; envelope-from=ard.biesheuvel@linaro.org; receiver=edk2-devel@lists.01.org Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 368102119F075 for ; Mon, 7 Jan 2019 09:33:39 -0800 (PST) Received: by mail-io1-xd44.google.com with SMTP id b16so973263ior.1 for ; Mon, 07 Jan 2019 09:33:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dBUl7pGkoKDEp4bwu7pIWzbuQZq20NpV+uVex2+shRQ=; b=gDuzi7l+b4sY8vvkwtqOGQULcq6AIs0cl6geCu0PGCCkPjJxnqzSehdIY3HMFpf/IM tdnzzc+jyiWR8ffse7yOuVIzZgk2GeZrgv+b3WDmfImu6+WQQa+tFM4099aM8vzp3L/8 211pox8Y29Qmhi0tUVga+CSyOqHVYtCeExECw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dBUl7pGkoKDEp4bwu7pIWzbuQZq20NpV+uVex2+shRQ=; b=DUC4UMaFx+sZoQ0bCLAbFvGGdX6lT/ZpURCB2qLHEGGx0VlPMb/4MTmtehsmTlrWDu WuCGvXtBqRat4r9+60s4cmTeXvvl9krYxvfghoB/38jBZUAp4kEdp78Rw2rtNgulgO8W 0sDmUREI/XpJtj4F81Utnq19su8AzvDJq7sP7Tf9otwUBKwdhvcvJtE7CY2D6hNSvRx7 nXEcac275jGsiuCi3107ib+SGpTBT3x/R1FbGpN2JAYBlgSyBpRhMu3jfT8/DpQbrN01 8B1gXyoE6z71CUE4H97YVjqvFN0fSf/UvDeljw/DL4HqWfF2hKJ1qp56Z4RGXCFOMnbR InPw== X-Gm-Message-State: AJcUukcso4WqZf6BbxsKKx9MUWcYgK3SVoQOOMb4eQFU2my2MYwgzTKp 0fi3QEPAVHEvZ+g5ku46edRTFhhpH+hUVY668AEL5A== X-Google-Smtp-Source: ALg8bN6S961AJ88EZ8qApnPigM1eHM9aUohk/1DrLraPhj4ClTFRp9BiprDbVzBuGxEDJvGWgUcgj3hAYkieO7WtEg4= X-Received: by 2002:a5e:c206:: with SMTP id v6mr27415613iop.60.1546882419097; Mon, 07 Jan 2019 09:33:39 -0800 (PST) MIME-Version: 1.0 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> In-Reply-To: From: Ard Biesheuvel Date: Mon, 7 Jan 2019 18:33:26 +0100 Message-ID: To: Laszlo Ersek 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 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 17:33:40 -0000 Content-Type: text/plain; charset="UTF-8" On Mon, 7 Jan 2019 at 16:28, Laszlo Ersek wrote: > > 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? > Perhaps Achin can answer this, since he has been driving the spec side of this? (and maintains StandaloneMmPkg)