From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.65; helo=mga03.intel.com; envelope-from=michael.d.kinney@intel.com; receiver=edk2-devel@lists.01.org Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 CB3DF2097F559 for ; Fri, 8 Feb 2019 09:59:26 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2019 09:59:26 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,348,1544515200"; d="scan'208";a="317442147" Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga006.fm.intel.com with ESMTP; 08 Feb 2019 09:59:25 -0800 Received: from orsmsx153.amr.corp.intel.com (10.22.226.247) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 8 Feb 2019 09:59:25 -0800 Received: from orsmsx113.amr.corp.intel.com ([169.254.9.97]) by ORSMSX153.amr.corp.intel.com ([169.254.12.21]) with mapi id 14.03.0415.000; Fri, 8 Feb 2019 09:59:25 -0800 From: "Kinney, Michael D" To: Andrew Fish , "Tomas Pilar (tpilar)" , "Kinney, Michael D" , "edk2-devel@lists.01.org" Thread-Topic: [edk2] Self-replicating image Thread-Index: AQHUv73aw0/2PeHkFkyEPqfW6nK9ZqXWqqcA//99C+A= Date: Fri, 8 Feb 2019 17:59:24 +0000 Message-ID: References: <5c8dff3b-3bbf-f317-efa9-277bc05b8b10@solarflare.com> <0AB73E14-5641-428D-9E4A-1D504A65885F@apple.com> In-Reply-To: <0AB73E14-5641-428D-9E4A-1D504A65885F@apple.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action x-originating-ip: [10.22.254.139] MIME-Version: 1.0 Subject: Re: Self-replicating image 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: Fri, 08 Feb 2019 17:59:27 -0000 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thomas, I have been looking into this topic of multiple controllers this week. I have some prototype code that I think resolves the issues but needs a bit more work on some corner cases. I am using the PCI Option ROM use case to evaluate the changes. PCI Option ROM can use Bus Specific Driver Override Protocol so the driver from the option ROM manages the PCI controller the option ROM is attached. PCI Option ROMs can also use the Driver Family Override Protocol so one of the PCI Option ROMs can manage a group of PCI controllers. It is also possible for an FMP driver for integrated devices to manage multiple integrated devices if there is more than one of the same device with FW storage. The multiple controller use case is not limited to busses like PCI. The current version of the FmpDeviceLib is optimized for an FMP instance that manages a single FW storage device. If an FmpDeviceLib is intended to manage multiple FW storage devices, then a few extra services in the FmpDeviceLib are required. The concept is to extend the FmpDeviceLib with a couple extra APIs that add support for Stop()/Unload() operations and to to set the context for the current FmpDeviceLib actions. Have you entered a BZ for this issue yet? I can start adding details in the BZ and post some proposed changes soon. Best regards, Mike > -----Original Message----- > From: edk2-devel [mailto:edk2-devel- > bounces@lists.01.org] On Behalf Of Andrew Fish via > edk2-devel > Sent: Friday, February 8, 2019 9:16 AM > To: Tomas Pilar (tpilar) > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] Self-replicating image >=20 >=20 >=20 > > On Feb 8, 2019, at 6:42 AM, Tomas Pilar (tpilar) > wrote: > > > > Hi, > > > > I am currently pondering the most elegant way to > implement capsule update for our devices that would > work in the presence of multiple devices in the host. > > > > Capsule allows embedding a driver that is executed > prior to the update, which is very handy. Crypto > library is quite large and would not fit into an > OptionROM, so being able to supply FMP driver in the > capsule is great. > > > > However, if only one instance of the driver loads, > the FMP upstream is currently written to support only > one device per instance. So I wonder if there is a > easy, neat way for my image to replicate on > DriverBinding so that I end up with one instance per > device. > > >=20 >=20 > Tom, >=20 > The usually model in EFI is to have one driver handle > multiple things. >=20 > > It looks like I should be able to do it with gBS- > >LoadImage() and passing information about currently > loaded image though I might have to CopyMem() the image > itself to new location. > > >=20 > gBS->LoadImage() will load and relocate the image to a > malloced address of the correct memory type for the > image. The inputs are just the source of the image, so > no need to CopyMem() anything. gBS->StartImage() calls > the entry point. >=20 > Thanks, >=20 > Andrew Fish >=20 > > Thoughts? > > > > Cheers, > > Tom > > _______________________________________________ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel >=20 > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel