From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=67.231.154.164; helo=dispatch1-us1.ppe-hosted.com; envelope-from=tpilar@solarflare.com; receiver=edk2-devel@lists.01.org Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 296B7208EB417 for ; Thu, 28 Feb 2019 02:49:05 -0800 (PST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (webmail.solarflare.com [12.187.104.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id A81EF28009D; Thu, 28 Feb 2019 10:49:04 +0000 (UTC) Received: from tp-desktop.uk.solarflarecom.com (10.17.20.51) by ocex03.SolarFlarecom.com (10.20.40.36) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 28 Feb 2019 02:49:00 -0800 To: "Kinney, Michael D" , Andrew Fish , "edk2-devel@lists.01.org" References: <5c8dff3b-3bbf-f317-efa9-277bc05b8b10@solarflare.com> <0AB73E14-5641-428D-9E4A-1D504A65885F@apple.com> <615c6c35-631c-6f7a-eaf4-ac91e2015f41@solarflare.com> From: "Tomas Pilar (tpilar)" Message-ID: <036c6eb3-c7e4-b3cd-fb37-27812cdbd3cc@solarflare.com> Date: Thu, 28 Feb 2019 10:48:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: X-Originating-IP: [10.17.20.51] X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24460.006 X-TM-AS-Result: No-21.933700-4.000000-10 X-TMASE-MatchedRID: cxtZ8fwm3r8V4Owxg5ZE4+Gonqgs5zxBuLwbhNl9B5W67Q3uPo9KI1Un QAOplXiGra3kAm8UOd29kty01+6pP0kkO4zqprNO++JNjskDoDPrKzHqnonLwhHfiujuTbedHAC UcDvcWyD3dZ1Cg8TR3cSHoZJgnGTyX9qDeSBmwI4SuhBXNJb1dGEF8bGZ0cKC2e73tJcoE9jWu8 1GT4rFibK1hNTbnBFA0hnaf64JwNwu7t78YsLO9RwU7wPa572vGbJMFqqIm9xjPrlNB+gMq9fof FZRoFPEGloaifZr8WRuaxXQ9wivZmDJAAe/0Re384dsinZ5e1j01irNvag5az0VIALmCAEKjNET HH9N9TaoJY4OOr0pA9080MwVG81ICb2L4BQ+AvtIRA38P/dwbkbbuL7Y47c0zsQ8iRVyD47HrYr 2+l5UMTh+dorQthV+sw3oj/eKbDGR45cat3SDypXi1z8zt1TRuIQDHu9PGw6POSMlTf7taPhi4L NMsvHZOLQhEmoPsvr6eiBFjkywYt8qyTrC2kZ55gCHftmwEMILitYSIrUiB+dTjSOFC/vqo8WMk QWv6iUD0yuKrQIMCIGsNX5eg/aOVnRXm1iHN1bEQdG7H66TyOk/y0w7JiZo X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--21.933700-4.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24460.006 X-MDID: 1551350945-ssWmjdlpvlzb 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: Thu, 28 Feb 2019 10:49:06 -0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Language: en-US Hi Mike, This all looks really good, I didn't envisage this way to design it (swapping contexts on demand) but it's much simpler than what I had in mind. I should be able to integrate this easily with my current FMP driver for our device and I should be able to get you some good testing. Cheers, Tom On 28/02/2019 03:33, Kinney, Michael D wrote: > Hi Tomas, > > I have posted a branch in edk2-staging with the proposed > design changes to support multiple controller and a functional > example in OVMF using multiple E1000 adapters. > > https://github.com/tianocore/edk2-staging/tree/Bug_1525_FmpDevicePkg_MultipleControllers > > QEMU has a few limitations, so some aspects are simulated, > but you should be able to use the example as a template to > try your use case. > > The E1000 UEFI PCI device driver that uses FmpDxe as a > Library is located at the following location. > > OvmfPkg/E1000Fmp > > It uses the E1000 specific FmpDeviceLib instance at: > > OvmfPkg/Feature/Capsule/Library/FmpDeviceLibE1000 > > I have added device specific DSC files for each FMP driver > that are included from the OVMF DSC file. The one for > E1000 is at: > > OvmfPkg/Feature/Capsule/FmpE1000.dsc > > QEMU does not support update of the PCI Option ROM > mapped to a PCI device. So I simulate the update of a > FW storage device using a 32-byte UEFI Variable that > is unique for each adapter. > > Best regards, > > Mike > >> -----Original Message----- >> From: Tomas Pilar (tpilar) >> [mailto:tpilar@solarflare.com] >> Sent: Monday, February 11, 2019 2:37 AM >> To: Kinney, Michael D ; >> Andrew Fish ; edk2-devel@lists.01.org >> Subject: Re: [edk2] Self-replicating image >> >> Hi Mike, >> >> Sorry to say I have not yet filed a BZ. Would you like >> me to, or are you happy doing it? >> >> Cheers, >> Tom >> >> On 08/02/2019 17:59, Kinney, Michael D wrote: >>> 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 >>>> >>>> >>>> >>>>> 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. >>>> >>>> Tom, >>>> >>>> The usually model in EFI is to have one driver >> handle >>>> multiple things. >>>> >>>>> 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. >>>> 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. >>>> >>>> Thanks, >>>> >>>> Andrew Fish >>>> >>>>> Thoughts? >>>>> >>>>> Cheers, >>>>> Tom >>>>> _______________________________________________ >>>>> edk2-devel mailing list >>>>> edk2-devel@lists.01.org >>>>> https://lists.01.org/mailman/listinfo/edk2-devel >>>> _______________________________________________ >>>> edk2-devel mailing list >>>> edk2-devel@lists.01.org >>>> https://lists.01.org/mailman/listinfo/edk2-devel