Re: Self-replicating image

["Kinney, Michael D" <michael.d.kinney@intel.com>]

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 <michael.d.kinney@intel.com>;
> Andrew Fish <afish@apple.com>; 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) <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