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=supreeth.venkatesh@arm.com; receiver=edk2-devel@lists.01.org Received: from foss.arm.com (foss.arm.com [217.140.101.70]) by ml01.01.org (Postfix) with ESMTP id A82C021B02845 for ; Mon, 23 Jul 2018 09:56:57 -0700 (PDT) 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 A90E418A; Mon, 23 Jul 2018 09:56:56 -0700 (PDT) Received: from [10.0.2.15] (u203142.usa.arm.com [10.118.30.82]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 5CEB73F5D0; Mon, 23 Jul 2018 09:56:56 -0700 (PDT) Message-ID: <1532365015.3302.15.camel@arm.com> From: Supreeth Venkatesh To: Ard Biesheuvel , Marvin H?user Cc: "edk2-devel@lists.01.org" , "achin.gupta@arm.com" , "jiewen.yao@intel.com" Date: Mon, 23 Jul 2018 11:56:55 -0500 In-Reply-To: References: X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 Subject: Re: StandaloneMmPkg comments X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 16:56:57 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit On Sun, 2018-07-22 at 00:51 +0900, Ard Biesheuvel wrote: > On 21 July 2018 at 03:57, Marvin H?user > wrote: > > > > Good day, > > > > I have been reading through the recently imported StandaloneMmPkg > > and found three odd things. > > > > > >   1.  GUID prefixes: GUIDs defined in StandaloneMmPkg.dec either > > have no common prefix at all ("gMmFv") or use the "gEfi" prefix. > > Maybe the MdeModulePkg-style "gEdkii" prefix could be used for a > > uniform style? > The gEdkii prefix is used for GUIDs that are not defined in the PI or > UEFI specs. The gEfi  prefix is used for GUIDs that are defined in > either of those specs. I'm not sure what the rule is for prefixless > GUIDs though. > > > > >   2.  The "gEfiMmConfigurationProtocolGuid" name is common between > > Standalone (StandaloneMmPkg.dec) and Traditional (MdePkg.dec) MM > > context despite having a different value of course. Shouldn't the > > naming reflect which is traditional and which is Standalone? I > > haven't checked in depth, but which is chosen when a module > > consumes both MdePkg and StandaloneMmPkg? > That smells like a bug to me. Sorry for the delayed response as I am catching up on emails after vacation.  I think that the naming should reflect which is traditional and which is Standalone even when traditional and standalone are supposed to be mutually exclusive. MdePkg.dec has this define gEfiMmConfigurationProtocolGuid= { 0x26eeb3de, 0xb689, 0x492e, { 0x80, 0xf0, 0xbe, 0x8b, 0xd7, 0xda, 0x4b, 0xa7 }} which is defined in PI Spec v1.6 vol 4 in section 5.5.  However, PI spec v1.6 vol 4 defines EFI_MM_CONFIGURATION_PROTOCOL_GUID once more in section 4.8 (Standalone MM context) as #define EFI_MM_CONFIGURATION_PROTOCOL_GUID { \ 0xc109319, 0xc149, 0x450e, 0xa3, 0xe3, 0xb9, 0xba, 0xdd, 0x9d, 0xc3, 0xa4 \ } Furthermore, it defines in Appendix A (Management Mode Backward Compatibility Types): #define EFI_SMM_CONFIGURATION_PROTOCOL_GUID EFI_MM_CONFIGURATION_PROTOCOL_GUID. It seems like an issue with the Specification. I have raised an ECR to get some clarification. https://mantis.uefi.org/mantis/view.php?id=1940   > > > > >   3.  While .dec already uses the "Mmram" naming scheme, its header > > declares the MemoryReserve GUID as > > "gEfiMmPeiS(!)mramMemoryReserveGuid". Furthermore, the header > > references the SMM CIS (which has been replaced with "MM CIS" as > > part of the renaming), while the GUID has changed and the structure > > does not match the deprecated specification anyway. May I suggest > > to turn this GUID into a "gEdkii"-style GUID and remove all > > references to the SMM CIS? Maybe use the "EDKII_" prefix for > > "EFI_MMRAM_HOB_DESCRIPTOR_BLOCK" too? I wanted to prepare a patch, > > but I cannot compile the package at the moment and don't want to > > risk submitting anything broken. > > > As mentioned above, EDKII prefixes are inappropriate here, since > standalone MM is defined in the PI spec. I will let others comment on > the SMM CIS thing.