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 C74861A1E0F for ; Fri, 30 Sep 2016 10:44:35 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 348408F267; Fri, 30 Sep 2016 17:44:35 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-73.phx2.redhat.com [10.3.116.73]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8UHiX4b011926; Fri, 30 Sep 2016 13:44:34 -0400 To: "Cohen, Eugene" , "edk2-devel@lists.01.org" , "Kinney, Michael D" , "Yao, Jiewen" , "Andrew Fish (afish@apple.com)" References: <9877647c-b348-2a36-9ac0-b520a82260d1@redhat.com> From: Laszlo Ersek Message-ID: <654a587b-8f79-51ef-8ba9-a29779de46c9@redhat.com> Date: Fri, 30 Sep 2016 19:44:33 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 30 Sep 2016 17:44:35 +0000 (UTC) Subject: Re: RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Sep 2016 17:44:36 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 09/30/16 18:36, Cohen, Eugene wrote: > Laszlo, > >> As far as I know: >> - the DXE and SMM protocol databases are distinct, >> - the same protocol GUID may or may not be installed (on one or more) >> handle(s) in either, >> - even if a protocol GUID exists uniquely in exactly one of those databases, >> the locator function would have to return which database the GUID was >> found. >> >> My point is that every wrapper function that returns a protocol interface (or >> several protocol interfaces), or handles, each such return value will likely >> have to be qualified with the database where it was found. > > The intent here is to only search the UEFI DB from a DXE/UEFI driver > and the SMM DB from an SMM driver and not to cross between. So which > protocol DB is searched is purely a function of the module type (i.e. > what instance of the ProtocolLib it was linked against). This is > analogous to what is done with MemoryAllocationLib which either > allocates from the UEFI memory pools for UEFI/DXE modules > (UefiMemoryAllocationLib instance) or from the SMM memory pools for > SMM modules (SmmMemoryAllocationLib). > > Sorry I wasn't more clear initially. I believe I understood this. However, in the entry point function of an SMM driver, it is permitted to look for, and invoke member functions of, both SMM and DXE protocols [1]. If the library instance that is supposed to be linked into SMM drivers is tied to the SMM protocol database solely, then it won't be able to serve the use case when an SMM driver looks for a DXE protocol in its entry point function. (Note I'm not speaking about "Combination SMM/DXE Drivers", just purely SMM drivers.) [1] "Vol4_SMM_1_4_Errata_A.pdf", section "1.7 SMM Driver Initialization": During SMM Driver initialization, SMM Drivers have access to two sets of protocols: UEFI and SMM. UEFI protocols are those which are installed and discovered using the UEFI Boot Services. UEFI protocols can be located and used by SMM drivers only during SMM Initialization. SMM protocols are those which are installed and discovered using the System Management Services Table (SMST). SMM protocols can be discovered by SMM drivers during initialization time and accessed while inside of SMM. [...] ... Actually, I believe this applies even to MemoryAllocationLib. In an SMM driver, the SMM-tailored MemoryAllocationLib instance only allocates SMRAM, which is mostly fine. However, it is unsuitable for allocating (for example) EfiBootServicesData type memory, even though that too is permitted in the SMM driver's entry point function, I think. For that, gBS->AllocatePool() or gBS->AllocatePages() have to be called explicitly. Thanks Laszlo