From: "gaoliming via groups.io" <gaoliming=byosoft.com.cn@groups.io>
To: <devel@edk2.groups.io>, <fan.wang@intel.com>,
"'Ni, Ray'" <ray.ni@intel.com>,
"'Kinney, Michael D'" <michael.d.kinney@intel.com>
Cc: "'Jiang, Guomin'" <guomin.jiang@intel.com>
Subject: 回复: [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support customized FV Migration Information
Date: Mon, 4 Dec 2023 19:46:43 +0800 [thread overview]
Message-ID: <007001da26a7$8dee0070$a9ca0150$@byosoft.com.cn> (raw)
In-Reply-To: <DM8PR11MB5752CA56FF3B2BD2ADDE34219786A@DM8PR11MB5752.namprd11.prod.outlook.com>
Fan:
I add my comment below.
> -----邮件原件-----
> 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Wang Fan
> 发送时间: 2023年12月4日 18:31
> 收件人: Ni, Ray <ray.ni@intel.com>; devel@edk2.groups.io; Gao, Liming
> <gaoliming@byosoft.com.cn>; Kinney, Michael D
> <michael.d.kinney@intel.com>
> 抄送: Jiang, Guomin <guomin.jiang@intel.com>
> 主题: Re: [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support customized
> FV Migration Information
>
> Thank you Ray and Liming, for your comments.
>
> Ray,
>
> There's something to clarify on this HOB usage. In this patch, when this
> Migration feature PCD is set to TRUE, the PeiCore will only migrate FVs which
> are recorded by ToMigrateFvInfo hob (each FV should publish their own
> ToMigrateFvInfo hob in this flow), and check MigrationFlags to decide also
> copy raw data or not. If no ToMigrateFvInfo hobs published, it will go into the
> legacy flow to migrate all FVs for backward compatibility.
>
> Agree on your suggestion on the flag name change to
> "FLAGS_BUILD_MIGRATED_FV_INFO", I will update in V4 patch. But I think a
> little different on your listed approaches: I prefer to refine the hob usage to
> include all ToMigrateFvInfo data in one hob (rather than each FV publish their
> own) and a field "MigrateAll" in this hob for those platforms who have no
> performance concern. In future, if we want to retire Migration feature PCD,
> we just need replace "check PCD TRUE or FALSE" with "check Hob exists or
> not". What do you think this way?
>
> Liming,
>
> For your question "RAW_DATA_COPY is for measure boot to make sure PCR0
> have the same value on the different boot.", we have
> gEfiPeiFirmwareVolumeInfoMeasurementExcludedPpiGuid to skip FV
> measurement when boot guard already measured these FVs. So I'm thinking
> it's valid to assume not all FVs need copy raw data for measurement.
[Liming] If so, please highlight this usage in comments that gEfiPeiFirmwareVolumeInfoMeasurementExcludedPpiGuid
must be configured if FV RAW_DATA_COPY is not set.
Thanks
Liming
>
> For your another question "If RemoveFvHobsInTemporaryMemory () does
> nothing now.", it's true from my investigation.
>
> Best Regards
> Fan
>
> -----Original Message-----
> From: Ni, Ray <ray.ni@intel.com>
> Sent: Friday, December 1, 2023 11:06 AM
> To: devel@edk2.groups.io; Gao, Liming <gaoliming@byosoft.com.cn>; Wang,
> Fan <fan.wang@intel.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>
> Cc: Jiang, Guomin <guomin.jiang@intel.com>; Bi, Dandan
> <dandan.bi@intel.com>
> Subject: RE: [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support
> customized FV Migration Information
>
> When PcdMigrateTemporaryRamFirmwareVolumes is TRUE, FV in flash
> (cached in code cache) is copied to physical memory and all C global pointers
> (PPIs, GUIDs) are fixed up.
> But TCG needs to measure the original FV contents, so the original FV is saved
> into MigratedFvInfo HOB when the FV migration is done.
>
> Now we are going to add a new ToMigrate HOB to tell something.
>
> Initially without reading the patch, I thought the HOB is to tell which FV needs
> to be migrated.
> But what the patch does is: migration is always done when PCD is true. The
> only thing that's skipped is not to save the original FV contents, then the
> MigratedFvInfo HOB is not produced as well.
> More strangely, if a FV is listed in "ToMigrate" HOB with flag 0, it's the same as
> the "ToMigrate" HOB does not exist.
>
> It's a bit confusing, in my opinion.
>
> There are several approaches:
> 1. Do not add "ToMigrate" HOB. Instead, avoid saving the whole original FV
> content, only save the delta that TCG driver uses the new FV content and the
> delta to calculate the HASH. The save of delta should not impact the
> performance very much.
>
> 2. Abandon the PCD, and update today's logic to follow the new "ToMigrate"
> HOB to perform migration. A new flag tells whether the original FV content
> needs to be saved.
>
> 3. Keep the PCD. If "ToMigrate" HOB does not exist, follow PCD. If "ToMigrate"
> HOB exists, follow the HOB and ignores the PCD. HOB takes higher priority.
> It's still backward compatible and allows edk2 to gradually retire that PCD.
> (Having multiple interfaces controlling one behavior is always confusing.)
> 3.1 The flag name in the patch is "*SKIP*". I prefer we reverse the meaning of
> the flag, meaning when the flag is set, FV original content is saved. The flag
> name can be "FLAGS_BUILD_MIGRATED_FV_INFO" which directly maps to
> the behavior the flag controls. I agree "MigratedFvInfo" name is confusing but
> at least we avoid adding another confusing "SKIP_FV_RAW_DATA_COPY" flag.
>
>
>
> Thanks,
> Ray
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of
> > gaoliming via groups.io
> > Sent: Friday, December 1, 2023 9:01 AM
> > To: devel@edk2.groups.io; Wang, Fan <fan.wang@intel.com>; Kinney,
> > Michael D <michael.d.kinney@intel.com>
> > Cc: Jiang, Guomin <guomin.jiang@intel.com>; Bi, Dandan
> > <dandan.bi@intel.com>
> > Subject: 回复: [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support
> > customized FV Migration Information
> >
> > Fan:
> > I add my comment below.
> >
> > > -----邮件原件-----
> > > 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Wang
> Fan
> > > 发送时间: 2023年10月27日 16:24
> > > 收件人: Kinney, Michael D <michael.d.kinney@intel.com>;
> > > devel@edk2.groups.io
> > > 抄送: Gao, Liming <gaoliming@byosoft.com.cn>; Jiang, Guomin
> > > <guomin.jiang@intel.com>; Bi, Dandan <dandan.bi@intel.com>
> > > 主题: Re: [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support
> > customized
> > > FV Migration Information
> > >
> > > Hi Mike
> > >
> > > Thank you for your feedback.
> > >
> > > I have updated the patch to v3:
> > > https://edk2.groups.io/g/devel/message/110197
> > >
> > > Pull Request: https://github.com/tianocore/edk2/pull/4970
> > >
> > > Based on V2, this update includes changes:
> > > - Add more descriptions for "gEdkiiToMigrateFvInfoGuid" PPI usages
> > > and background, but still keep the name.
> > > - Update "FvOrgBase" to "FvTemporaryRamBase" in
> > > EDKII_TO_MIGRATE_FV_INFO.
> > > - Remove flag "FLAGS_SKIP_FV_MIGRATION", since it's not needed.
> > > - Add more descriptions to flag "FLAGS_SKIP_FV_RAW_DATA_COPY".
> > [Liming] RAW_DATA_COPY is for measure boot to make sure PCR0 have the
> > same value on the different boot.
> > If RAW_DATA_COPY is not set, it will impact the measure boot. So, I
> > don't think we can skip raw data copy.
> >
> > > - Remove the variable MigrateAllFvs to simplify logic.
> > > - Correct "allocate pool" to "allocate pages" to align with descriptions.
> > >
> > > For other two questions you are mentioning:
> > >
> > > 1. For "Should FvOrgBase be a UINT64 or support temp RAM above
> 4GB?":
> > > I think UINT32 should be enough, all pre-mem FVs are below 4G as far
> > > as I know, even we enabled X64 in pre-mem phase. This setting is
> > > also aligning with "FvOrgBase" defined in "EDKII_MIGRATED_FV_INFO".
> > > 2. For "The call to RemoveFvHobsInTemporaryMemory (Private) was
> > > removed":
> > > Since this function will remove all FV hobs for physical addresses,
> > > it
> > should be
> > > called only when all pre-mem FVs are migrated. In EvacuateTempRam(),
> > when
> > > one FV is migrated, ConvertFvHob() will be called for this FV and all its'
> > child
> > > FVs, this is enough to ensure already migrated FV hobs are all
> > > pointing to addresses on permanent address.
> > >
> > [Liming] So, RemoveFvHobsInTemporaryMemory () does nothing now. Right?
> > If yes, it is safe to remove it.
> >
> > Thanks
> > Liming
> > > What do you think?
> > >
> > > Best Regards
> > > Fan
> > >
> > > -----Original Message-----
> > > From: Kinney, Michael D <michael.d.kinney@intel.com>
> > > Sent: Tuesday, October 17, 2023 5:00 AM
> > > To: Wang, Fan <fan.wang@intel.com>; devel@edk2.groups.io
> > > Cc: Gao, Liming <gaoliming@byosoft.com.cn>; Jiang, Guomin
> > > <guomin.jiang@intel.com>; Bi, Dandan <dandan.bi@intel.com>; Kinney,
> > > Michael D <michael.d.kinney@intel.com>
> > > Subject: RE: [PATCH V2 1/1] MdeModulePkg: Support customized FV
> > > Migration Information
> > >
> > > Hi Fan,
> > >
> > > The logic looks functional, but there are some names and
> > > descriptions that could be added to help describe this feature and
> > > some code changes to make the code easier to understand.
> > >
> > > 1) The GUID gEdkiiToMigrateFvInfoGuid is hard to understand what
> > > information it conveys from the name of the GUID variable.
> > > I know that the intent is that it is a GUID with data that
> > > tells the PEI core which FVs in temporary RAM should be
> > > migrated to permanent RAM. And that the use of this information
> > > is only a performance optimization to not migrate FVs that
> > > are not needed after the PEI Core migrates temp RAM to
> > > permanent RAM. The name and description in comments do not
> > > express all these details.
> > >
> > > 2) The structure name EDKII_TO_MIGRATE_FV_INFO has the same
> > > issue as (1).
> > > a) Should FvOrgBase be a UINT64 or support temp RAM above 4GB?
> > > b) Since only temp RAM to perm RAM migrations are supported
> > > the field name "FvOrgBase" should be "FvTemporaryRamBase".
> > >
> > >
> > > 3) The #define for FLAGS_SKIP_FV_MIGRATION should have a comment
> > > block that describes the meaning of this bit. What is the
> > > meaning when the bit is set and what is the meaning when the
> > > bit is clear.
> > >
> > > 4) The #define for FLAGS_SKIP_FV_RAW_DATA_COPY should have a
> > comment
> > > block that describes the meaning of this bit. What is the
> > > meaning when the bit is set and what is the meaning when the
> > > bit is clear.
> > >
> > > 5) Why are there 2 bits? If an FV is skipped, then that means
> > > do not copy. If an FV is not skipped, then that means do
> > > copy.
> > >
> > > 6) I think the variable MigrateAllFvs can be removed, and the HOB
> > > list check can be made for gEdkiiToMigrateFvInfoGuid can be made
> > > on each FV found in temporary RAM. This looks like a performance
> > > optimization that makes the logic harder to understand and it
> > > is not clear that the performance optimization has any benefit.
> > >
> > > 7) The call to RemoveFvHobsInTemporaryMemory (Private) was removed.
> > > Why?
> > >
> > > 8) The comment where memory is allocated for the migrated FV says
> > > "allocate pool" when PeiServicesAllocatePages() is used. Please
> > > update the comment.
> > >
> > > Mike
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Wang, Fan <fan.wang@intel.com>
> > > > Sent: Monday, September 11, 2023 2:52 AM
> > > > To: devel@edk2.groups.io
> > > > Cc: Wang, Fan <fan.wang@intel.com>; Kinney, Michael D
> > > > <michael.d.kinney@intel.com>; Gao, Liming
> > > > <gaoliming@byosoft.com.cn>; Jiang, Guomin
> > > > <guomin.jiang@intel.com>; Bi, Dandan <dandan.bi@intel.com>
> > > > Subject: [PATCH V2 1/1] MdeModulePkg: Support customized FV
> > Migration
> > > > Information
> > > >
> > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4533
> > > >
> > > > There are use cases which not all FVs need be migrated from
> > > > TempRam to permanent memory before TempRam tears down. This
> new
> > > > guid is introduced to avoid unnecessary FV migration to improve
> > > > boot performance.
> > > > Platform
> > > > can publish ToMigrateFvInfo hob with this guid to customize FV
> > > > migration info, and PeiCore will only migrate FVs indicated by
> > > > this Hob info.
> > > >
> > > > This is a backwards compatible change, PeiCore will check
> > > > ToMigrateFvInfo hob before migration. If ToMigrateFvInfo hobs
> > > > exists, only migrate FVs recorded by hobs. If ToMigrateFvInfo hobs
> > > > not exists, migrate all FVs to permanent memory.
> > > >
> > > > Cc: Michael D Kinney <michael.d.kinney@intel.com>
> > > > Cc: Liming Gao <gaoliming@byosoft.com.cn>
> > > > Cc: Guomin Jiang <guomin.jiang@intel.com>
> > > > Cc: Dandan Bi <dandan.bi@intel.com>
> > > > Signed-off-by: Wang Fan <fan.wang@intel.com>
> > > > ---
> > > > MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 82
> > > +++++++++++++-----
> > > > -
> > > > MdeModulePkg/Core/Pei/PeiMain.inf | 1 +
> > > > MdeModulePkg/Include/Guid/MigratedFvInfo.h | 19 +++++
> > > > MdeModulePkg/MdeModulePkg.dec | 3 +-
> > > > 4 files changed, 79 insertions(+), 26 deletions(-)
> > > >
> > > > diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> > > > b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> > > > index 5f32ebb560ae..e84849ec6db1 100644
> > > > --- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> > > > +++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
> > > > @@ -1184,7 +1184,11 @@ EvacuateTempRam (
> > > >
> > > > PEI_CORE_FV_HANDLE PeiCoreFvHandle;
> > > > EFI_PEI_CORE_FV_LOCATION_PPI *PeiCoreFvLocationPpi;
> > > > + EDKII_TO_MIGRATE_FV_INFO *ToMigrateFvInfo;
> > > > EDKII_MIGRATED_FV_INFO MigratedFvInfo;
> > > > + EFI_PEI_HOB_POINTERS Hob;
> > > > + BOOLEAN MigrateAllFvs;
> > > > + UINT32 MigrationFlags;
> > > >
> > > > ASSERT (Private->PeiMemoryInstalled);
> > > >
> > > > @@ -1211,6 +1215,17 @@ EvacuateTempRam (
> > > >
> > > > ConvertPeiCorePpiPointers (Private, &PeiCoreFvHandle);
> > > >
> > > > + //
> > > > + // Check if platform defined hobs to indicate which FVs are
> > > > expected to migrate or keep raw data.
> > > > + // If ToMigrateFvInfo hobs exists, only migrate FVs recorded by
> > > > hobs.
> > > > + // If ToMigrateFvInfo hobs not exists, migrate all FVs to
> > > > + permanent
> > > > memory.
> > > > + //
> > > > + MigrateAllFvs = TRUE;
> > > > + Hob.Raw = GetFirstGuidHob (&gEdkiiToMigrateFvInfoGuid);
> > > > + if (Hob.Raw != NULL) {
> > > > + MigrateAllFvs = FALSE;
> > > > + }
> > > > +
> > > > for (FvIndex = 0; FvIndex < Private->FvCount; FvIndex++) {
> > > > FvHeader = Private->Fv[FvIndex].FvHeader;
> > > > ASSERT (FvHeader != NULL);
> > > > @@ -1224,6 +1239,25 @@ EvacuateTempRam (
> > > > )
> > > > )
> > > > {
> > > > + if (MigrateAllFvs) {
> > > > + MigrationFlags = 0;
> > > > + } else {
> > > > + MigrationFlags = FLAGS_SKIP_FV_MIGRATION |
> > > > FLAGS_SKIP_FV_RAW_DATA_COPY;
> > > > + Hob.Raw = GetFirstGuidHob (&gEdkiiToMigrateFvInfoGuid);
> > > > + while (Hob.Raw != NULL) {
> > > > + ToMigrateFvInfo = GET_GUID_HOB_DATA (Hob);
> > > > + if (ToMigrateFvInfo->FvOrgBase ==
> > > (UINT32)(UINTN)FvHeader)
> > > > {
> > > > + MigrationFlags = ToMigrateFvInfo->MigrationFlags;
> > > > + break;
> > > > + }
> > > > + Hob.Raw = GET_NEXT_HOB (Hob);
> > > > + Hob.Raw = GetNextGuidHob (&gEdkiiToMigrateFvInfoGuid,
> > > > Hob.Raw);
> > > > + }
> > > > + }
> > > > + if (MigrationFlags & FLAGS_SKIP_FV_MIGRATION) {
> > > > + continue;
> > > > + }
> > > > +
> > > > //
> > > > // Allocate page to save the rebased PEIMs, the PEIMs will
> > > > get dispatched later.
> > > > //
> > > > @@ -1234,18 +1268,7 @@ EvacuateTempRam (
> > > > );
> > > > ASSERT_EFI_ERROR (Status);
> > > > MigratedFvHeader = (EFI_FIRMWARE_VOLUME_HEADER
> > > > *)(UINTN)FvHeaderAddress;
> > > > -
> > > > - //
> > > > - // Allocate pool to save the raw PEIMs, which is used to keep
> > > > consistent context across
> > > > - // multiple boot and PCR0 will keep the same no matter if the
> > > > address of allocated page is changed.
> > > > - //
> > > > - Status = PeiServicesAllocatePages (
> > > > - EfiBootServicesCode,
> > > > - EFI_SIZE_TO_PAGES
> ((UINTN)FvHeader->FvLength),
> > > > - &FvHeaderAddress
> > > > - );
> > > > - ASSERT_EFI_ERROR (Status);
> > > > - RawDataFvHeader = (EFI_FIRMWARE_VOLUME_HEADER
> > > > *)(UINTN)FvHeaderAddress;
> > > > + CopyMem (MigratedFvHeader, FvHeader, (UINTN)FvHeader-
> > > > >FvLength);
> > > >
> > > > DEBUG ((
> > > > DEBUG_VERBOSE,
> > > > @@ -1256,18 +1279,29 @@ EvacuateTempRam (
> > > > ));
> > > >
> > > > //
> > > > - // Copy the context to the rebased pages and raw pages, and
> > > > create hob to save the
> > > > - // information. The MigratedFvInfo HOB will never be produced
> > > > when
> > > > - // PcdMigrateTemporaryRamFirmwareVolumes is FALSE,
> because
> > > the
> > > > PCD control the
> > > > - // feature.
> > > > + // Copy the context to the raw pages, and create hob to
> > > > + save
> > > > the information. The MigratedFvInfo
> > > > + // HOB will never be produced when
> > > > PcdMigrateTemporaryRamFirmwareVolumes is FALSE, because the PCD
> > > > + // controls the feature.
> > > > //
> > > > - CopyMem (MigratedFvHeader, FvHeader, (UINTN)FvHeader-
> > > > >FvLength);
> > > > - CopyMem (RawDataFvHeader, MigratedFvHeader,
> > > (UINTN)FvHeader-
> > > > >FvLength);
> > > > - MigratedFvInfo.FvOrgBase = (UINT32)(UINTN)FvHeader;
> > > > - MigratedFvInfo.FvNewBase =
> > > (UINT32)(UINTN)MigratedFvHeader;
> > > > - MigratedFvInfo.FvDataBase =
> (UINT32)(UINTN)RawDataFvHeader;
> > > > - MigratedFvInfo.FvLength =
> > > (UINT32)(UINTN)FvHeader->FvLength;
> > > > - BuildGuidDataHob (&gEdkiiMigratedFvInfoGuid,
> &MigratedFvInfo,
> > > > sizeof (MigratedFvInfo));
> > > > + if ((MigrationFlags & FLAGS_SKIP_FV_RAW_DATA_COPY) !=
> > > > FLAGS_SKIP_FV_RAW_DATA_COPY) {
> > > > + //
> > > > + // Allocate pool to save the raw PEIMs, which is used to
> > > > + keep
> > > > consistent context across
> > > > + // multiple boot and PCR0 will keep the same no matter if
> > > > + the
> > > > address of allocated page is changed.
> > > > + //
> > > > + Status = PeiServicesAllocatePages (
> > > > + EfiBootServicesCode,
> > > > + EFI_SIZE_TO_PAGES
> > > ((UINTN)FvHeader->FvLength),
> > > > + &FvHeaderAddress
> > > > + );
> > > > + ASSERT_EFI_ERROR (Status);
> > > > + RawDataFvHeader = (EFI_FIRMWARE_VOLUME_HEADER
> > > > *)(UINTN)FvHeaderAddress;
> > > > + CopyMem (RawDataFvHeader, MigratedFvHeader,
> > > (UINTN)FvHeader-
> > > > >FvLength);
> > > > + MigratedFvInfo.FvOrgBase = (UINT32)(UINTN)FvHeader;
> > > > + MigratedFvInfo.FvNewBase =
> > > (UINT32)(UINTN)MigratedFvHeader;
> > > > + MigratedFvInfo.FvDataBase =
> > > (UINT32)(UINTN)RawDataFvHeader;
> > > > + MigratedFvInfo.FvLength = (UINT32)(UINTN)FvHeader-
> > > > >FvLength;
> > > > + BuildGuidDataHob (&gEdkiiMigratedFvInfoGuid,
> > > &MigratedFvInfo,
> > > > sizeof (MigratedFvInfo));
> > > > + }
> > > >
> > > > //
> > > > // Migrate any children for this FV now @@ -1330,8 +1364,6
> > > > @@ EvacuateTempRam (
> > > > }
> > > > }
> > > >
> > > > - RemoveFvHobsInTemporaryMemory (Private);
> > > > -
> > > > return Status;
> > > > }
> > > >
> > > > diff --git a/MdeModulePkg/Core/Pei/PeiMain.inf
> > > > b/MdeModulePkg/Core/Pei/PeiMain.inf
> > > > index 0cf357371a16..944b230b0e19 100644
> > > > --- a/MdeModulePkg/Core/Pei/PeiMain.inf
> > > > +++ b/MdeModulePkg/Core/Pei/PeiMain.inf
> > > > @@ -78,6 +78,7 @@
> > > > gEfiFirmwareFileSystem3Guid
> > > > gStatusCodeCallbackGuid
> > > > gEdkiiMigratedFvInfoGuid ##
> > > SOMETIMES_PRODUCES
> > > > ## HOB
> > > > + gEdkiiToMigrateFvInfoGuid ##
> > > SOMETIMES_CONSUMES
> > > > ## HOB
> > > >
> > > > [Ppis]
> > > > gEfiPeiStatusCodePpiGuid ##
> > > SOMETIMES_CONSUMES
> > > > # PeiReportStatusService is not ready if this PPI doesn't exist
> > > > diff --git a/MdeModulePkg/Include/Guid/MigratedFvInfo.h
> > > > b/MdeModulePkg/Include/Guid/MigratedFvInfo.h
> > > > index aca2332a0ec6..543cd9ba7ddd 100644
> > > > --- a/MdeModulePkg/Include/Guid/MigratedFvInfo.h
> > > > +++ b/MdeModulePkg/Include/Guid/MigratedFvInfo.h
> > > > @@ -9,6 +9,24 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> > > > #ifndef __EDKII_MIGRATED_FV_INFO_GUID_H__ #define
> > > > __EDKII_MIGRATED_FV_INFO_GUID_H__
> > > >
> > > > +#define FLAGS_SKIP_FV_MIGRATION BIT0
> > > > +#define FLAGS_SKIP_FV_RAW_DATA_COPY BIT1
> > > > +
> > > > +///
> > > > +/// EDKII_TO_MIGRATE_FV_INFO Hob information should be published
> > by
> > > > platform to indicate
> > > > +/// one FV is expected to migrate to permarnant memory or not
> > > > +before
> > > > TempRam tears down.
> > > > +///
> > > > +typedef struct {
> > > > + UINT32 FvOrgBase; // original FV address
> > > > + //
> > > > + // Migration Flags:
> > > > + // Bit0: Indicate to skip FV migration or not
> > > > + // Bit1: Indicate to skip FV raw data copy or not
> > > > + // Others: Reserved bits
> > > > + //
> > > > + UINT32 MigrationFlags;
> > > > +} EDKII_TO_MIGRATE_FV_INFO;
> > > > +
> > > > typedef struct {
> > > > UINT32 FvOrgBase; // original FV address
> > > > UINT32 FvNewBase; // new FV address
> > > > @@ -16,6 +34,7 @@ typedef struct {
> > > > UINT32 FvLength; // Fv Length
> > > > } EDKII_MIGRATED_FV_INFO;
> > > >
> > > > +extern EFI_GUID gEdkiiToMigrateFvInfoGuid;
> > > > extern EFI_GUID gEdkiiMigratedFvInfoGuid;
> > > >
> > > > #endif // #ifndef __EDKII_MIGRATED_FV_INFO_GUID_H__ diff --git
> > > > a/MdeModulePkg/MdeModulePkg.dec
> > > b/MdeModulePkg/MdeModulePkg.dec index
> > > > dd182c02fdf6..d6cbcc721a5e 100644
> > > > --- a/MdeModulePkg/MdeModulePkg.dec
> > > > +++ b/MdeModulePkg/MdeModulePkg.dec
> > > > @@ -416,7 +416,8 @@
> > > > gEdkiiCapsuleOnDiskNameGuid = { 0x98c80a4f, 0xe16b, 0x4d11, {
> > > > 0x93, 0x9a, 0xab, 0xe5, 0x61, 0x26, 0x3, 0x30 } }
> > > >
> > > > ## Include/Guid/MigratedFvInfo.h
> > > > - gEdkiiMigratedFvInfoGuid = { 0xc1ab12f7, 0x74aa, 0x408d, {
> > > > 0xa2, 0xf4, 0xc6, 0xce, 0xfd, 0x17, 0x98, 0x71 } }
> > > > + gEdkiiToMigrateFvInfoGuid = { 0xb4b140a5, 0x72f6, 0x4c21, {
> > > > + 0x93,
> > > > 0xe4, 0xac, 0xc4, 0xec, 0xcb, 0x23, 0x23 } }
> > > > + gEdkiiMigratedFvInfoGuid = { 0xc1ab12f7, 0x74aa, 0x408d, {
> > > > + 0xa2,
> > > > 0xf4, 0xc6, 0xce, 0xfd, 0x17, 0x98, 0x71 } }
> > > >
> > > > ## Include/Guid/RngAlgorithm.h
> > > > gEdkiiRngAlgorithmUnSafe = { 0x869f728c, 0x409d, 0x4ab4, {0xac,
> > > > 0x03, 0x71, 0xd3, 0x09, 0xc1, 0xb3, 0xf4 }}
> > > > --
> > > > 2.29.2.windows.2
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112037): https://edk2.groups.io/g/devel/message/112037
Mute This Topic: https://groups.io/mt/102968594/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
next prev parent reply other threads:[~2023-12-04 11:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <cover.1694425833.git.fan.wang@intel.com>
2023-09-11 9:51 ` [edk2-devel] [PATCH V2 1/1] MdeModulePkg: Support customized FV Migration Information Wang Fan
2023-10-16 20:59 ` Michael D Kinney
2023-10-27 8:23 ` Wang Fan
2023-11-20 6:30 ` Wang Fan
2023-12-01 1:01 ` 回复: " gaoliming via groups.io
2023-12-01 3:05 ` Ni, Ray
2023-12-04 10:31 ` Wang Fan
2023-12-04 11:46 ` gaoliming via groups.io [this message]
2023-12-05 8:16 ` Ni, Ray
[not found] ` <1783CF665DB6E42F.23877@groups.io>
2023-09-22 5:32 ` Wang Fan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='007001da26a7$8dee0070$a9ca0150$@byosoft.com.cn' \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox