On Tue, Jan 10, 2023 at 09:36:59AM +0000, Ni, Ray wrote: > > >>> The challenge is that the non-Itanium CPU archs that may depend on the > > >>> current binary layout of these structures. This could be a binary > > >>> PEI CPU module, DXE CPU module, SMM CPU module, MM CPU modules, > > >>> UEFI App/Shell App that use the PPI or HOB. > > The CPU health record is stored in PPI first by SecCore, then saved to HOB by > CpuMpPei module. > Then CpuDxe gets the record from HOB. > > If SecCore, CpuMpPei, CpuDxe are built with different structure definition, > the compatibility issue appears. > > The very well know binary separation module today for x86 is Intel's FSP. > I am not sure if today customer might use a pre-built FSP binary which is > built from > version #1 of edk2 while the SecCore and CpuDxe in platform binary are built > from > a different version of edk2. > I don't know how AMD distributes the binary module. + Tom > > If binary distribution is not adopted yet by industry, I prefer we just > update the > structure definition.
Yes. *That* is the big question. Just removing ITANIUM_HANDOFF_STATUS is source compatible but not binary compatible. For OVMF just updating the structure definition is not a problem at all because the complete firmware image is built in one go from the source code, so there are never incompatible modules. So if compatibility at source level works for everybody we can do just that, and maybe additionally change the GUIDs so any incompatibilities would not go unnoticed. > > >>> Even if we define a new HOB format, we have to decide when it is > > >>> used to support compatibility. Perhaps always keep the current > > >>> logic if < 1024 CPUs. If number of CPUs >= 1024, then produce > > >>> the new format of CPU information and update all consumers to > > >>> look for new format and use that with higher priority than the > > >>> old format. > > I don't like this approach because it still breaks the case when CPU >=1024 > and binary > distribution is used. Well. We already have EFI_SEC_PLATFORM_INFORMATION_RECORD + EFI_SEC_PLATFORM_INFORMATION_RECORD2 and some code which is able to work with both formats. See for example CollectBistDataFromPpi(). So in case binary compatibility is required we probably have to add EFI_SEC_PLATFORM_INFORMATION_RECORD3 Maybe it is possible to remove support for EFI_SEC_PLATFORM_INFORMATION_RECORD at the same time. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98244): https://edk2.groups.io/g/devel/message/98244 Mute This Topic: https://groups.io/mt/95384808/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
