From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on071c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe48::71c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C394C1A1DE9 for ; Mon, 10 Oct 2016 08:24:06 -0700 (PDT) Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.25) by AT5PR84MB0292.NAMPRD84.PROD.OUTLOOK.COM (10.162.138.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.659.11; Mon, 10 Oct 2016 15:24:03 +0000 Received: from AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) by AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM ([10.162.138.25]) with mapi id 15.01.0659.020; Mon, 10 Oct 2016 15:24:04 +0000 From: "Cohen, Eugene" To: "Gao, Liming" , Laszlo Ersek , "edk2-devel@lists.01.org" , "Kinney, Michael D" , "Yao, Jiewen" , "Andrew Fish (afish@apple.com)" Thread-Topic: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Handle Services Thread-Index: AdIbIt8zDF4zYVg0Qm6BbTDEpt2HcgAA5RyAAARYvtAAAp28gAAI576gAZpdBoAATn70sA== Date: Mon, 10 Oct 2016 15:24:03 +0000 Message-ID: References: <9877647c-b348-2a36-9ac0-b520a82260d1@redhat.com> <654a587b-8f79-51ef-8ba9-a29779de46c9@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14B4820B6@shsmsx102.ccr.corp.intel.com> In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14B4820B6@shsmsx102.ccr.corp.intel.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eugene@hp.com; x-originating-ip: [15.65.252.13] x-ms-office365-filtering-correlation-id: b5631912-3932-4754-be01-08d3f121782f x-microsoft-exchange-diagnostics: 1; AT5PR84MB0292; 6:CSe7dwylUx4NQCOcHBL12UeP61UQumfiaSM5FG4w37quXruQS94m0E9wqWCz+59TL+KGd1+SSOxtyBOCyK2Hc3O0ngHrLSvxI/j7vnn/HwkL3gab0BBagJF+/BkVVE+O4uVMg+SN27isYAeCPoxd7EspXTLBnhFMUh62gR/1USQXXIOhlQ/bQGaa2crRRh/WDArPP22/kZmHoc1aRqz/H6cpRUE5Bzlvn+ZFB7nn/hhKAD66gEe7djt79CHV86OUojJzfefuKbWafiJA4UTl9yXUU1ue/UfDhcRNHL/hC3/9mul4EUCPxcwoK1CpuJLv; 5:5uM/E08FdEmnoe3MdVZTuSEBR/0m0APLtfK5oLJpar9B5tlQuBT2nEEf8/u16sA7M1Xona0u/uPgtlHcWFqPjbG2OofxIOxztNYeTwXAJLc/r3doV+CSf04KoBVnpl0Ef0WxfVv6v12u1VhtjqhipA==; 24:ZD5sbF2MKw6AS3On0wjMV/wrmKgO/3qG2SxI+V13dh3R+y4VN7UXV5C3T/+RL2E0CIqPvzHnpVSGE8tOTuzZZ7t17sSiRLwZprRHeATg6lc=; 7:63lI8r8qAkx8wpbMfzlweF0tp4N3ifSMB2bB89rTEXAZiLOTyr+oViuWoIZXSKz2KEA7lVKcr3QWhq/B89pleZP3g2zaxlKdoqW8miygAfFpMa6mFOrjAo0AzQQGoPF8jyiEfBZiEReXms6UxTB1KJPjwEF6tlMhu+KdSfrEEtm/ADM3GhTtEFd8CxxSMNPPx5SFXKs6HgvYteZh82kPCQNrZ1WVz4kRGN6pZBQFsVH6WcT81VLDh9Gr/g2mJUIJvKtRC6Dtd7473S8gTm6odv74mIXbJoxl/ijylqkBjSX0berVFabRG4i6ZW4VvrdMneP+MliOvKdYTGB7YxWO91fa2smuc8s+u3QwQ80p1z0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0292; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(162533806227266)(21748063052155)(31960201722614)(228905959029699)(73583498263828); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AT5PR84MB0292; BCL:0; PCL:0; RULEID:; SRVR:AT5PR84MB0292; x-forefront-prvs: 0091C8F1EB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(6602003)(199003)(377454003)(19617315012)(5001770100001)(5002640100001)(6116002)(790700001)(3846002)(102836003)(15975445007)(77096005)(93886004)(66066001)(2900100001)(122556002)(8666005)(3660700001)(97736004)(3280700002)(86362001)(8676002)(10400500002)(7906003)(8936002)(7736002)(81166006)(81156014)(87936001)(7846002)(99286002)(50986999)(92566002)(68736007)(16236675004)(9686002)(5660300001)(2906002)(76176999)(54356999)(74316002)(107886002)(2950100002)(586003)(19580405001)(189998001)(33656002)(19625215002)(19580395003)(561944003)(19300405004)(106356001)(7696004)(101416001)(105586002)(7059030)(491001)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:AT5PR84MB0292; H:AT5PR84MB0291.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: hp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: hp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2016 15:24:03.9028 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ca7981a2-785a-463d-b82a-3db87dfc3ce6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0292 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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: Mon, 10 Oct 2016 15:24:07 -0000 Content-Language: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Liming, > Could this library cover PEI PPI? Yes - excellent suggestion for PEI - I hadn't considered it because the use= case hadn't come up for me yet. > And, I think this library class will include Install, Notify and Locate A= PIs. Right? Yes, this library class proposal incorporates all of the protocol and handl= e database related functionality. Notify may be tricky since in DXE we hav= e TPL and both PEI and SMM we have direct function callbacks but perhaps th= ere's a way to abstract if we assume a default TPL or an alternate library = API to initialize the callback TPL in advance. (On the other hand this cou= ld introduce subtle bugs if driver developers lose sight of the TPL used fo= r callbacks on this interface.) Given the positive feedback the next step is to publish a proposed library = header file for review. Thanks, Eugene From: Gao, Liming [mailto:liming.gao@intel.com] Sent: Saturday, October 08, 2016 7:50 PM To: Cohen, Eugene ; Laszlo Ersek ; edk2-d= evel@lists.01.org ; Kinney, Michael D ; Yao, Jiewen ; Andrew Fish (afish@app= le.com) Subject: RE: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Han= dle Services Eugene: Could this library cover PEI PPI? LocatePpi and LocateProtocol both retur= n VOID**. And, I think this library class will include Install, Notify and = Locate APIs. Right? typedef EFI_STATUS (EFIAPI *EFI_PEI_LOCATE_PPI)( IN CONST EFI_PEI_SERVICES **PeiServices, IN CONST EFI_GUID *Guid, IN UINTN Instance, IN OUT EFI_PEI_PPI_DESCRIPTOR **PpiDescriptor OPTIONAL, IN OUT VOID **Ppi ); typedef EFI_STATUS (EFIAPI *EFI_LOCATE_PROTOCOL)( IN EFI_GUID *Protocol, IN VOID *Registration, OPTIONAL OUT VOID **Interface ); Thanks Liming From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Cohe= n, Eugene Sent: Saturday, October 1, 2016 6:05 AM To: Laszlo Ersek >; edk2-devel@= lists.01.org >; Kinney, Michael D >; Yao, Jiewen >; Andrew Fish (afish@apple.com) > Subject: Re: [edk2] RFC: ProtocolLib for cross DXE and SMM Protocol and Han= dle Services > 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. Agreed - non-standalone SMM drivers (notice the new terminology I'm injecti= ng to prepare us for PI 1.5) can peek over at UEFI/DXE. This is not the use= case I'm trying to enable here (and I would argue as an industry is a prac= tice we will try to discourage over time). > ... 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. Right - so the common library abstraction allocates from the "native" memor= y pool for the driver type and if you want something else you have to go ab= ove and beyond. So in the spirit of that precedent I'd propose the same app= roach for a ProtocolLib implementation. Thanks, great feedback. Eugene _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel