Hi Scott,

I would agree that the current logic that checks for uniqueness applies to V3+ of an EFI_FIRMWARE_IMAGE_DESCRITOR.

Below V3, the HardwareInstance field does not exist, so I agree that the uniqueness check and ASSERT can not be done. The language around V3 that introduced fields like HardwareInstance sites examples like PCI add-in cards as to why the field was added. So I would not expect to see an FMP instance from a PCI add-in card that is below V3.

If we remove the uniqueness check and ASSERT at versions below V2, then we need to also review the capsule processing to determine how capsules are processed. If the capsule has a non zero HardwareInstance and the FMP with the matching GUID is below V3, is the capsule ignored? Perhaps only capsules with a zero HardwareInstance value can be dispatched to an FMP with version below V3?

Thanks,

Mike

From: scott.wiginton@hpe.com <scott.wiginton@hpe.com>
Sent: Monday, October 21, 2019 6:12 AM
To: Kinney, Michael D <michael.d.kinney@intel.com>; devel@edk2.groups.io
Subject: Re: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs

Michael,

Wouldn't the current implementation ASSERT if there are different plug-in cards by the same vendor using the same GUID in their FMP?  They are managing different hardware and have no knowledge of the existence of the other FMP instance.  Each FMP is only aware of the specific device on whose handle they are installed.  If they use FW image descriptors below version 2 (or they cannot determine a unique HW instance), this would always be 0.  Why would we want to ASSERT in this case?  What error condition is being caught?

Thanks,
SWig