Re: Self-replicating image

["Tomas Pilar (tpilar)" <tpilar@solarflare.com>]

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) <tpilar@solarflare.com>
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] Self-replicating image
>>
>>
>>
>>> On Feb 8, 2019, at 6:42 AM, Tomas Pilar (tpilar)
>> <tpilar@solarflare.com> 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