From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=217.140.101.70; helo=foss.arm.com; envelope-from=jagadeesh.ujja@arm.com; receiver=edk2-devel@lists.01.org Received: from foss.arm.com (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by ml01.01.org (Postfix) with ESMTP id 4EDDC20886F25 for ; Mon, 25 Feb 2019 00:17:55 -0800 (PST) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7272A1596 for ; Mon, 25 Feb 2019 00:17:54 -0800 (PST) Received: from mail-it1-f176.google.com (usa-sjc-mx-foss1.foss.arm.com [217.140.101.70]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 576B23F73B for ; Mon, 25 Feb 2019 00:17:54 -0800 (PST) Received: by mail-it1-f176.google.com with SMTP id z124so12026826itc.2 for ; Mon, 25 Feb 2019 00:17:54 -0800 (PST) X-Gm-Message-State: AHQUAuaSfmSQN187Kf2Ph9f1jikT35TghSYVJIe/s/4a3q1tb0r/j0K+ L0krKONB2JOxDE+l1VsrDYZcFw98BL0Tv1o1kRY= X-Google-Smtp-Source: AHgI3IbI54VTWjmxM9g4/I4nVBA6aLEmV6mTNl5tgz7pxIOnJSNCWSL6dhz4CgNTAWXx9yyBUDIVrlcPjybaH98J6SE= X-Received: by 2002:a02:4084:: with SMTP id n126mr8230252jaa.78.1551082673475; Mon, 25 Feb 2019 00:17:53 -0800 (PST) MIME-Version: 1.0 References: <1550570820-29379-1-git-send-email-jagadeesh.ujja@arm.com> <615a9ac8-1ca9-94e1-a473-b251dae57460@redhat.com> In-Reply-To: From: Jagadeesh Ujja Date: Mon, 25 Feb 2019 13:47:42 +0530 X-Gmail-Original-Message-ID: Message-ID: To: Ard Biesheuvel Cc: "Zeng, Star" , "edk2-devel@lists.01.org" , "Gao, Liming" , "Yao, Jiewen" , "Kinney, Michael D" , Laszlo Ersek , "Zhang, Chao B" Subject: Re: [PATCH] MdeModulePkg/VariableSmmRuntimeDxe: Refactor locating Variable Arch Protocol 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, 25 Feb 2019 08:17:55 -0000 Content-Type: text/plain; charset="UTF-8" Hi Ard/Star On Thu, Feb 21, 2019 at 3:15 PM Ard Biesheuvel wrote: > > On Thu, 21 Feb 2019 at 10:33, Zeng, Star wrote: > > > > On 2019/2/21 17:11, Ard Biesheuvel wrote: > > > On Thu, 21 Feb 2019 at 10:04, Laszlo Ersek wrote: > > >> > > >> On 02/20/19 13:23, Ard Biesheuvel wrote: > > >>> On Wed, 20 Feb 2019 at 06:53, Jagadeesh Ujja wrote: > > >>>> > > >>>> hi Ard, > > >>>> On Tue, Feb 19, 2019 at 6:55 PM Ard Biesheuvel > > >>>> wrote: > > >>>>> > > >>>>> Hello Jagadeesh, > > >>>>> > > >>>>> On Tue, 19 Feb 2019 at 11:47, Jagadeesh Ujja wrote: > > >>>>>> > > >>>>>> In preparation for providing a standalone MM based non-secure variable > > >>>>>> runtime driver, factor out some portions that are specific to the > > >>>>>> traditional driver, mainly related to locating variable arch protocol > > >>>>>> and variable write arch protocol, which are not required to be located > > >>>>>> when using standalone MM based secure variable implementation. > > >>>>>> > > >>>>> > > >>>>> While i think this change is correct from a technical perspective, I > > >>>>> don't think this is the right approach. > > >>>>> > > >>>> these changes are mandatory, this is one of the possible solution. > > >>>> > > >>>>> It was a deliberate decision to expose the MM services in a way that > > >>>>> only the producer of the communication protocol is aware of the > > >>>>> implementation details, i.e., whether it is backed by tradtional MM or > > >>>>> standalone MM. > > >>>>> > > >>>> can you please provide more details on how "exposing the MM services" > > >>>> will help to resolve the issue here. if this helps, definitely i will use that. > > >>>> > > >>> > > >>> Let me rephrase this for the benefit of the MdeModulePkg maintainers, > > >>> and ask them their opinion. > > >>> > > >>> Currently, the DXE runtime driver that produces the architectural > > >>> varstore protocols that are based on communication with MM components > > >>> living elsewhere, rely on the EFI protocol database for sequencing. > > >>> I.e., after dispatch, they wait for certain protocols to be installed > > >>> into the DXE protocol database by the SMM drivers before proceeding to > > >>> install the variable arch protocols. > > >>> > > >>> This does not work for standalone MM, since it has no access to the > > >>> DXE protocol database, nor is it needed, since it may be assumed that > > >>> the MM execution context is fully configured by the time the DXE phase > > >>> starts. > > >>> > > >>> Jagadeesh's proposal is to factor this out, and create two different > > >>> .INFs to build the same DXE runtime driver in two different ways. This > > >>> defeats the purpose of having an abstract MM communication protocol, > > >>> so it is something I would like to avoid. On the other hand, is it not > > >>> obvious how to parameterize this requirement in another way. > > >>> > > >>> For the moment, I could live with putting this into a library, and > > >>> leave it up to the platform to ensure the combination of the library > > >>> resolution with the driver that produces the MM communicate protocol > > >>> is a sane one. > > >>> > > >>> Any thoughts? > > >> > > >> I think I'm missing the gist of the library approach; still, would it be > > >> possible for affected platforms (i.e. those that depend on standalone > > >> MM) to procude the necessary DXE protocols (for unblocking the variable > > >> runtime driver) in a platform DXE driver? > > >> > > > > > > Yes, that is the other option: we could create a library that > > > unconditionally produces those protocols and hook it into the MM > > > communication driver via NULL library class resolution. > > > > > > > I am not familiar with standalone MM, either ARM. So may have no much > > valuable opinion. > > > > For this case, standalone MM could not install DXE protocols into DXE > > protocol database to notify the wrapper (VariableSmmRuntimeDxe), so need > > another way to install the DXE protocols, right? > > Yes > > > Could standalone MM assume the MM handler for variable is ready when MM > > communication driver runs? > > Yes > > > If yes, a NULL library instance should work (as a stub to install the > > DXE protocols in its constructor). :) > > > > Yes, that was my suggestion. > > So Jagadeesh, could you please take this approach instead? > thanks for the inputs. Sorry i was on leave, will do the necessary changes and Soon will submit the patches for review. > - Create a library in StandaloneMmPkg with LIBRARY_CLASS = NULL and a > constructor that installs the two protocols. > - Update your platform so that the MM communication driver is included as > > ArmPkg/Drivers/MmCommunicationDxe/MmCommunication.inf { > > NULL|StandaloneMmPkg/Library/VariableMmDependency/VariableMmDependency.inf > } > > I don't think this will violate any ordering constraints, given that > the drivers that have a dependency on these protocols also have a > dependency on the MM communicate driver itself. > > Thanks, > Ard. > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel