Re: [edk2-devel] [PATCH 1/1] UefiCpuPkg/PiSmmCpuDxeSmm: Add check for pointer Pml5Entry
Reviewed-by: Ray Ni > -Original Message- > From: Zhang, Shenglei > Sent: Wednesday, July 31, 2019 1:57 PM > To: de...@edk2.groups.io; edk2-devel@lists.01.org > Cc: Dong, Eric ; Ni, Ray ; Laszlo > Ersek > Subject: [PATCH 1/1] UefiCpuPkg/PiSmmCpuDxeSmm: Add check for pointer > Pml5Entry > > The pointer Pml5Entry, returned from call to function > AllocatePageTableMemory, may be null. > So add check for it. > > Cc: Eric Dong > Cc: Ray Ni > Cc: Laszlo Ersek > Signed-off-by: Shenglei Zhang > --- > UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c > b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c > index a3b62f778741..d7af3b6d7941 100644 > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c > @@ -375,6 +375,7 @@ SmmInitPageTable ( > // Fill PML5 entry > // > Pml5Entry = (UINT64*)AllocatePageTableMemory (1); > +ASSERT (Pml5Entry != NULL); > *Pml5Entry = (UINTN) Pml4Entry | mAddressEncMask | > PAGE_ATTRIBUTE_BITS; > ZeroMem (Pml5Entry + 1, EFI_PAGE_SIZE - sizeof (*Pml5Entry)); > // > -- > 2.18.0.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#44665): https://edk2.groups.io/g/devel/message/44665 Mute This Topic: https://groups.io/mt/32662314/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2] [RFC] Remove Nt32Pkg
All, Now since EmulatorPkg supports to run in Windows environment, I propose to remove Nt32Pkg. Do you have any concern on the Nt32Pkg removal? Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] UefiCpuPkg/Cpuid: Dump leaf 1FH information correctly
> -Original Message-
> From: Dong, Eric
> Sent: Wednesday, April 3, 2019 2:40 PM
> To: Ni, Ray ; edk2-devel@lists.01.org
> Subject: RE: [PATCH] UefiCpuPkg/Cpuid: Dump leaf 1FH information correctly
>
> Hi Ray,
>
> > -Original Message-
> > From: Ni, Ray
> > Sent: Friday, March 29, 2019 4:42 PM
> > To: edk2-devel@lists.01.org
> > Cc: Dong, Eric
> > Subject: [PATCH] UefiCpuPkg/Cpuid: Dump leaf 1FH information correctly
> >
> > Leaf 1FH is very similar to leaf 0BH. Both return the CPU topology
> information.
> > Leaf 0BH returns 3-level (Package/Core/Thread) CPU topology info.
> > Leaf 1FH returns 6-level (Package/Die/Tile/Module/Core/Thread) CPU
> > topology info.
> > The logic to enumerate the topology info is the same.
> >
> > But today's logic to handle 1FH is completely wrong.
> > The patch combines them together to fix the 1FH issue.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ray Ni
> > Cc: Eric Dong
> > ---
> > UefiCpuPkg/Application/Cpuid/Cpuid.c | 83
> > ++--
> > 1 file changed, 28 insertions(+), 55 deletions(-)
> >
> > diff --git a/UefiCpuPkg/Application/Cpuid/Cpuid.c
> > b/UefiCpuPkg/Application/Cpuid/Cpuid.c
> > index 67cacf2714..3d242a0cbf 100644
> > --- a/UefiCpuPkg/Application/Cpuid/Cpuid.c
> > +++ b/UefiCpuPkg/Application/Cpuid/Cpuid.c
> > @@ -1,7 +1,7 @@
> > /** @file
> >UEFI Application to display CPUID leaf information.
> >
> > - Copyright (c) 2016 - 2018, Intel Corporation. All rights
> > reserved.
> > + Copyright (c) 2016 - 2019, Intel Corporation. All rights
> > + reserved.
> >This program and the accompanying materials
> >are licensed and made available under the terms and conditions of
> > the BSD License
> >which accompanies this distribution. The full text of the license
> > may be found at @@ -717,36 +717,42 @@
> > CpuidArchitecturalPerformanceMonitoring ( **/ VOID
> > CpuidExtendedTopology (
> > - VOID
> > + UINT32 LeafFunction
> >)
> > {
> > - CPUID_EXTENDED_TOPOLOGY_EAX Eax;
> > - CPUID_EXTENDED_TOPOLOGY_EBX Ebx;
> > - CPUID_EXTENDED_TOPOLOGY_ECX Ecx;
> > - UINT32 Edx;
> > - UINT32 LevelNumber;
> > + CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_EAX Eax;
> > + CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_EBX Ebx;
> > + CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_ECX Ecx;
> > + UINT32 Edx;
> > + UINT32 LevelNumber;
> >
> > - if (CPUID_EXTENDED_TOPOLOGY > gMaximumBasicFunction) {
> > + if (LeafFunction > gMaximumBasicFunction) {
> > +return;
> > + }
> > + if ((LeafFunction != CPUID_EXTENDED_TOPOLOGY) && (LeafFunction !=
> > + CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION)) {
> > return;
> >}
> >
> >LevelNumber = 0;
> > - do {
> > + for (LevelNumber = 0; ; LevelNumber++) {
> > AsmCpuidEx (
> > - CPUID_EXTENDED_TOPOLOGY, LevelNumber,
> > + LeafFunction, LevelNumber,
> >, , ,
> >);
> > -if (Eax.Bits.ApicIdShift != 0) {
> > - Print (L"CPUID_EXTENDED_TOPOLOGY (Leaf %08x, Sub-Leaf %08x)\n",
> > CPUID_EXTENDED_TOPOLOGY, LevelNumber);
> > - Print (L" EAX:%08x EBX:%08x ECX:%08x EDX:%08x\n", Eax.Uint32,
> > Ebx.Uint32, Ecx.Uint32, Edx);
> > - PRINT_BIT_FIELD (Eax, ApicIdShift);
> > - PRINT_BIT_FIELD (Ebx, LogicalProcessors);
> > - PRINT_BIT_FIELD (Ecx, LevelNumber);
> > - PRINT_BIT_FIELD (Ecx, LevelType);
> > - PRINT_VALUE (Edx, x2APIC_ID);
> > +if (Ecx.Bits.LevelType ==
> > CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION_LEVEL_TYPE_INVALID)
> {
> > + break;
> > }
> > -LevelNumber++;
> > - } while (Eax.Bits.ApicIdShift != 0);
> > +Print (
> > + L"%a (Leaf %08x, Sub-Leaf %08x)\n",
> > + LeafFunction == CPUID_EXTENDED_TOPOLOGY ?
> > "CPUID_EXTENDED_TOPOLOGY" :
> > "CPUID_V2_EXTENDED_TOPOLOGY_ENUMERATION-2",
> > + LeafFunction, LevelNumber);
> > +Print (L" EAX:%08x EBX:%08x ECX:%08x EDX:%08x\n", Eax.Uint32,
> > Ebx.Uint32, Ecx.Uint32, Edx);
> > +PRINT_BIT_FIELD (Eax, BitsNum);
> > +PRINT_BIT_FIELD (Ebx, ProcessorsNum);
> > +PRINT_BIT_FIELD (Ecx, LevelNum);
> > +PRINT_BIT_FIELD (E
Re: [edk2] [Patch v2] UefiCpuPkg/MpInitLib: Fix MemTest86 failure.
Reviewed-by: Ray Ni
> -Original Message-
> From: Dong, Eric
> Sent: Wednesday, April 3, 2019 10:46 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray
> Subject: [Patch v2] UefiCpuPkg/MpInitLib: Fix MemTest86 failure.
>
> V2 changes:
> Update the commit message and comments in the code.
>
> When waking vector buffer allocated by CpuDxe is tested by MemTest86
> in MP mode, an error is reported because the same range of memory is
> modified by both CpuDxe driver and MemTest86.
>
> The waking vector buffer is not expected to be tested by MemTest86 if
> it is allocated out because MemTest86 only tests free memory. But
> current CpuDxe driver "borrows" buffer instead of allocate buffer for
> waking vector buffer (through allocate & free to get the buffer
> pointer, backup the buffer data before using it and restore it after
> using). With this implementation, if the buffer borrowed is not used
> by any other drivers, MemTest86 tool will treat it as free memory
> and test it.
>
> In order to fix the above issue, CpuDxe changes to allocate the
> buffer below 1M instead of borrowing it. But directly allocating
> memory below 1MB causes LegacyBios driver fails to start. LegacyBios
> driver allocates memory range from
> "0xA - PcdEbdaReservedMemorySize" to 0xA as Ebda Reserved
> Memory. The minimum value for "0xA - PcdEbdaReservedMemorySize"
> is 0x88000. If LegacyBios driver allocate this range failed, it
> asserts.
>
> LegacyBios also reserves range from 0x6 to
> "0x6 + PcdOpromReservedMemorySize", it will be used as Oprom
> Reserve Memory. The maximum value for "0x6 +
> PcdOpromReservedMemorySize" is 0x88000. LegacyBios driver tries to
> allocate these range page(4K size) by page. It just reports warning
> message if some pages are already allocated by others.
> Base on above investigation, one page in range 0x6 ~ 0x88000 can
> be used as the waking vector buffer.
>
> LegacyBios driver only reports warning when page allocation in range
> [0x6, 0x88000) fails. This library is consumed by CpuDxe driver
> to produce CPU Arch protocol. LagacyBios driver depends on CPU Arch
> protocol which guarantees below allocation runs earlier than
> LegacyBios driver.
>
> Cc: Ray Ni
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong
> ---
> UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 26 ++---
> 1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> index b2307cbb61..cef5b49dde 100644
> --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> @@ -76,7 +76,7 @@ SaveCpuMpData (
> }
>
> /**
> - Get available system memory below 1MB by specified size.
> + Get available system memory below 0x88000 by specified size.
>
>@param[in] WakeupBufferSize Wakeup buffer size required
>
> @@ -91,7 +91,15 @@ GetWakeupBuffer (
>EFI_STATUS Status;
>EFI_PHYSICAL_ADDRESSStartAddress;
>
> - StartAddress = BASE_1MB;
> + //
> + // Try to allocate buffer below 1M for waking vector.
> + // LegacyBios driver only reports warning when page allocation in range
> + // [0x6, 0x88000) fails.
> + // This library is consumed by CpuDxe driver to produce CPU Arch protocol.
> + // LagacyBios driver depends on CPU Arch protocol which guarantees below
> + // allocation runs earlier than LegacyBios driver.
> + //
> + StartAddress = 0x88000;
>Status = gBS->AllocatePages (
>AllocateMaxAddress,
>EfiBootServicesData,
> @@ -99,17 +107,13 @@ GetWakeupBuffer (
>
>);
>ASSERT_EFI_ERROR (Status);
> - if (!EFI_ERROR (Status)) {
> -Status = gBS->FreePages(
> - StartAddress,
> - EFI_SIZE_TO_PAGES (WakeupBufferSize)
> - );
> -ASSERT_EFI_ERROR (Status);
> -DEBUG ((DEBUG_INFO, "WakeupBufferStart = %x, WakeupBufferSize = %x\n",
> -(UINTN) StartAddress, WakeupBufferSize));
> - } else {
> + if (EFI_ERROR (Status)) {
> StartAddress = (EFI_PHYSICAL_ADDRESS) -1;
>}
> +
> + DEBUG ((DEBUG_INFO, "WakeupBufferStart = %x, WakeupBufferSize = %x\n",
> + (UINTN) StartAddress, WakeupBufferSize));
> +
>return (UINTN) StartAddress;
> }
>
> --
> 2.21.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master
> -Original Message- > From: edk2-devel On Behalf Of Laszlo > Ersek > Sent: Tuesday, April 2, 2019 4:49 PM > To: Bi, Dandan ; edk2-devel@lists.01.org > Cc: Cetola, Stephano ; Kinney, Michael D > ; Gao, Liming ; Carsey, > Jaben > Subject: Re: [edk2] [RFC] Plan to delete ShellBinPkg from edk2/master > > On 04/02/19 07:38, Bi, Dandan wrote: > > Hi All, > > > > ShellBinPkg is the remaining binary package in Edk2 repo. We plan to > delete ShellBinPkg from edk2/master, and keep source ShellPkg only in edk2 > repo. > > Before the deletion, I will update the existing consumers in Edk2 and > Edk2Platforms to use ShellPkg directly. > > > > If you have any concern please raise here before mid-April . If there is no > concern, I will create patches for this task after mid-April. > > > > Bugzilla for this task: > > https://bugzilla.tianocore.org/show_bug.cgi?id=1675 > > (adding a few CC's) > > I think we should not remove ShellBinPkg without a replacement > *somehwere*. > > A shell binary that is built from a validated edk2 tree, with a set of library > resolutions and PCD settings that are known to keep platform dependencies > *out* of the shell binary, is extremely useful. I understand the concern. Maybe a "Shell.dsc.inc" provided by ShellPkg which lists all library resolutions , PCD settings and build options can be included by platform DSC to resolve such dependency issue. > > IIRC, Andrew suggested earlier that we should treat the shell even as an "OS", > with better compatibility standards than we currently maintain. > > I think we should only remove ShellBinPkg if we permanently offer a > separate download location instead, and we rebuild the shell binary from > "ShellPkg/ShellPkg.dsc" at every stable tag. I do not quite understand. All other modules in edk2 repo are source-included by OvmfPkg and daily commits directly generates new binaries for OvmfPkg. I do not think we should have a different "binary-generation" model for shell. > > In that case, removing ShellBinPkg would indeed improve the edk2 tree, in > my opinion. > > Thanks, > Laszlo > ___ > 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
Re: [edk2] [Patch v2 4/4] UefiCpuPkg/RegisterCpuFeaturesLib: Correct comments.
Reviewed-by: Ray Ni > -Original Message- > From: Dong, Eric > Sent: Friday, March 1, 2019 1:40 PM > To: edk2-devel@lists.01.org > Cc: Ni, Ray ; Laszlo Ersek > Subject: [Patch v2 4/4] UefiCpuPkg/RegisterCpuFeaturesLib: Correct comments. > > Cc: Ray Ni > Cc: Laszlo Ersek > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Eric Dong > --- > UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git > a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c > b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c > index 3e8e899766..a78ef44491 100644 > --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c > +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c > @@ -1174,8 +1174,8 @@ PreSmmCpuRegisterTableWrite ( >@param[in] CpuBitMaskSize The size of CPU feature bit mask buffer >@param[in] Feature The bit number of the CPU feature > > - @retval TRUE The CPU feature is set in PcdCpuFeaturesSupport. > - @retval FALSE The CPU feature is not set in PcdCpuFeaturesSupport. > + @retval TRUE The CPU feature is set in CpuBitMask. > + @retval FALSE The CPU feature is not set in CpuBitMask. > > **/ > BOOLEAN > -- > 2.15.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch v2 3/4] UefiCpuPkg/RegisterCpuFeaturesLib: Simplify PcdCpuFeaturesSupport.
Reviewed-by: Ray Ni
> -Original Message-
> From: edk2-devel On Behalf Of Eric Dong
> Sent: Friday, March 1, 2019 1:40 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch v2 3/4] UefiCpuPkg/RegisterCpuFeaturesLib: Simplify
> PcdCpuFeaturesSupport.
>
> PcdCpuFeaturesSupport used to specify the platform policy about what CPU
> features this platform supports. This PCD will be used in
> IsCpuFeatureSupported
> only.
>
> Now RegisterCpuFeaturesLib use this PCD as an template to Get the pcd size.
> Update the code logic to replace it with PcdCpuFeaturesSetting.
>
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1375
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong
> ---
> .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 43
> +-
> .../RegisterCpuFeaturesLib/RegisterCpuFeatures.h | 1 -
> .../RegisterCpuFeaturesLib.c | 10 ++---
> 3 files changed, 22 insertions(+), 32 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> index d877caff74..c82f848b97 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> @@ -245,11 +245,6 @@ CpuInitDataInitialize (
>ASSERT (CpuFeaturesData->CpuFlags.CoreSemaphoreCount != NULL);
>CpuFeaturesData->CpuFlags.PackageSemaphoreCount = AllocateZeroPool
> (sizeof (UINT32) * CpuStatus->PackageCount * CpuStatus->MaxCoreCount *
> CpuStatus->MaxThreadCount);
>ASSERT (CpuFeaturesData->CpuFlags.PackageSemaphoreCount != NULL);
> -
> - //
> - // Get support and configuration PCDs
> - //
> - CpuFeaturesData->SupportPcd = GetSupportPcd ();
> }
>
> /**
> @@ -269,7 +264,7 @@ SupportedMaskOr (
>UINT8 *Data1;
>UINT8 *Data2;
>
> - BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
> + BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
>Data1 = SupportedFeatureMask;
>Data2 = OrFeatureBitMask;
>for (Index = 0; Index < BitMaskSize; Index++) { @@ -294,7 +289,7 @@
> SupportedMaskAnd (
>UINT8 *Data1;
>UINT8 *Data2;
>
> - BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
> + BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
>Data1 = SupportedFeatureMask;
>Data2 = AndFeatureBitMask;
>for (Index = 0; Index < BitMaskSize; Index++) { @@ -319,7 +314,7 @@
> SupportedMaskCleanBit (
>UINT8 *Data1;
>UINT8 *Data2;
>
> - BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
> + BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
>Data1 = SupportedFeatureMask;
>Data2 = AndFeatureBitMask;
>for (Index = 0; Index < BitMaskSize; Index++) { @@ -350,7 +345,7 @@
> IsBitMaskMatch (
>UINT8 *Data1;
>UINT8 *Data2;
>
> - BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
> + BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
>
>Data1 = SupportedFeatureMask;
>Data2 = ComparedFeatureBitMask;
> @@ -389,21 +384,19 @@ CollectProcessorData (
>Entry = GetFirstNode (>FeatureList);
>while (!IsNull (>FeatureList, Entry)) {
> CpuFeature = CPU_FEATURE_ENTRY_FROM_LINK (Entry);
> -if (IsBitMaskMatch (CpuFeaturesData->SupportPcd, CpuFeature-
> >FeatureMask)) {
> - if (CpuFeature->SupportFunc == NULL) {
> -//
> -// If SupportFunc is NULL, then the feature is supported.
> -//
> -SupportedMaskOr (
> - CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
> - CpuFeature->FeatureMask
> - );
> - } else if (CpuFeature->SupportFunc (ProcessorNumber, CpuInfo,
> CpuFeature-
> >ConfigData)) {
> -SupportedMaskOr (
> - CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
> - CpuFeature->FeatureMask
> - );
> - }
> +if (CpuFeature->SupportFunc == NULL) {
> + //
> + // If SupportFunc is NULL, then the feature is supported.
> + //
> + SupportedMaskOr (
> +CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
> +CpuFeature->FeatureMask
> +);
> +} else if (CpuFeature->SupportFunc (ProcessorNumber, CpuInfo, CpuFeature-
> >ConfigData)) {
> + SupportedMaskOr (
> +CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
> +CpuFeature->FeatureMask
> +);
> }
> Entry = Entry->ForwardLink;
>}
> @@ -596,8 +589,6 @@ AnalysisProcessorFeatures (
>DumpCpuFeature (CpuFeature);
>Entry = Entry->ForwardLink;
> }
> -DEBUG ((DEBUG_INFO, "PcdCpuFeaturesSupport:\n"));
> -DumpCpuFeatureMask (CpuFeaturesData->SupportPcd);
> DEBUG ((DEBUG_INFO, "PcdCpuFeaturesCapability:\n"));
> DumpCpuFeatureMask
Re: [edk2] [Patch v2 2/4] UefiCpuPkg/RegisterCpuFeaturesLib: Optimize PCD PcdCpuFeaturesUserConfiguration.
Minor comments:
1. Please add "CONST" before AndFeatureBitMask to declare that it won't be
changed in the routine.
SupportedMaskAnd (
IN UINT8 *SupportedFeatureMask,
IN CONST UINT8 *AndFeatureBitMask
)
2. Please update the year in the copyright.
With these comments addressed, Reviewed-by: Ray Ni
> -Original Message-
> From: edk2-devel On Behalf Of Eric Dong
> Sent: Friday, March 1, 2019 1:40 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch v2 2/4] UefiCpuPkg/RegisterCpuFeaturesLib: Optimize
> PCD PcdCpuFeaturesUserConfiguration.
>
> Merge PcdCpuFeaturesUserConfiguration into PcdCpuFeaturesSetting.
> Use PcdCpuFeaturesSetting as input for the user input feature setting Use
> PcdCpuFeaturesSetting as output for the final CPU feature setting
>
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1375
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong
> ---
> .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 71
> +-
> .../DxeRegisterCpuFeaturesLib.inf | 3 +-
> .../PeiRegisterCpuFeaturesLib.inf | 3 +-
> .../RegisterCpuFeaturesLib/RegisterCpuFeatures.h | 1 -
> UefiCpuPkg/UefiCpuPkg.dec | 9 +--
> 5 files changed, 21 insertions(+), 66 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> index bae92b89a6..d877caff74 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> @@ -21,16 +21,21 @@ CHAR16 *mRegisterTypeStr[] = {L"MSR", L"CR",
> L"MMIO", L"CACHE", L"SEMAP", L"INVA
>Worker function to save PcdCpuFeaturesCapability.
>
>@param[in] SupportedFeatureMask The pointer to CPU feature bits mask
> buffer
> + @param[in] FeatureMaskSize CPU feature bits mask buffer size.
> +
> **/
> VOID
> SetCapabilityPcd (
> - IN UINT8 *SupportedFeatureMask
> + IN UINT8 *SupportedFeatureMask,
> + IN UINT32 FeatureMaskSize
>)
> {
>EFI_STATUS Status;
>UINTN BitMaskSize;
>
>BitMaskSize = PcdGetSize (PcdCpuFeaturesCapability);
> + ASSERT (FeatureMaskSize == BitMaskSize);
> +
>Status = PcdSetPtrS (PcdCpuFeaturesCapability, ,
> SupportedFeatureMask);
>ASSERT_EFI_ERROR (Status);
> }
> @@ -53,48 +58,6 @@ SetSettingPcd (
>ASSERT_EFI_ERROR (Status);
> }
>
> -/**
> - Worker function to get PcdCpuFeaturesSupport.
> -
> - @return The pointer to CPU feature bits mask buffer.
> -**/
> -UINT8 *
> -GetSupportPcd (
> - VOID
> - )
> -{
> - UINT8 *SupportBitMask;
> -
> - SupportBitMask = AllocateCopyPool (
> - PcdGetSize (PcdCpuFeaturesSupport),
> - PcdGetPtr (PcdCpuFeaturesSupport)
> - );
> - ASSERT (SupportBitMask != NULL);
> -
> - return SupportBitMask;
> -}
> -
> -/**
> - Worker function to get PcdCpuFeaturesUserConfiguration.
> -
> - @return The pointer to CPU feature bits mask buffer.
> -**/
> -UINT8 *
> -GetConfigurationPcd (
> - VOID
> - )
> -{
> - UINT8 *SupportBitMask;
> -
> - SupportBitMask = AllocateCopyPool (
> - PcdGetSize (PcdCpuFeaturesUserConfiguration),
> - PcdGetPtr (PcdCpuFeaturesUserConfiguration)
> - );
> - ASSERT (SupportBitMask != NULL);
> -
> - return SupportBitMask;
> -}
> -
> /**
>Collects CPU type and feature information.
>
> @@ -287,7 +250,6 @@ CpuInitDataInitialize (
>// Get support and configuration PCDs
>//
>CpuFeaturesData->SupportPcd = GetSupportPcd ();
> - CpuFeaturesData->ConfigurationPcd = GetConfigurationPcd (); }
>
> /**
> @@ -610,16 +572,9 @@ AnalysisProcessorFeatures (
>//
>// Calculate the last setting
>//
> -
>CpuFeaturesData->SettingPcd = AllocateCopyPool (CpuFeaturesData-
> >BitMaskSize, CpuFeaturesData->CapabilityPcd);
>ASSERT (CpuFeaturesData->SettingPcd != NULL);
> - SupportedMaskAnd (CpuFeaturesData->SettingPcd, CpuFeaturesData-
> >ConfigurationPcd);
> -
> - //
> - // Save PCDs and display CPU PCDs
> - //
> - SetCapabilityPcd (CpuFeaturesData->CapabilityPcd);
> - SetSettingPcd (CpuFeaturesData->SettingPcd);
> + SupportedMaskAnd (CpuFeaturesData->SettingPcd, PcdGetPtr
> + (PcdCpuFeaturesSetting));
>
>//
>// Dump the last CPU feature list
> @@ -643,14 +598,20 @@ AnalysisProcessorFeatures (
> }
> DEBUG ((DEBUG_INFO, "PcdCpuFeaturesSupport:\n"));
> DumpCpuFeatureMask (CpuFeaturesData->SupportPcd);
> -DEBUG ((DEBUG_INFO, "PcdCpuFeaturesUserConfiguration:\n"));
> -DumpCpuFeatureMask (CpuFeaturesData->ConfigurationPcd);
> DEBUG ((DEBUG_INFO, "PcdCpuFeaturesCapability:\n"));
> DumpCpuFeatureMask (CpuFeaturesData->CapabilityPcd);
> -DEBUG ((DEBUG_INFO, "PcdCpuFeaturesSetting:\n"));
> +
Re: [edk2] [Patch v2 1/4] UefiCpuPkg/RegisterCpuFeaturesLib: Remove useless functions.
Reviewed-by: Ray Ni
Please remember to update the year in copyright when pushing.
> -Original Message-
> From: edk2-devel On Behalf Of Eric Dong
> Sent: Friday, March 1, 2019 1:40 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch v2 1/4] UefiCpuPkg/RegisterCpuFeaturesLib: Remove
> useless functions.
>
> Remove useless APIs, simplify the code logic.
>
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1375
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong
> ---
> .../Include/Library/RegisterCpuFeaturesLib.h | 34 ---
> .../RegisterCpuFeaturesLib.c | 50
> --
> 2 files changed, 84 deletions(-)
>
> diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> index 2f7e71c833..073f020d0b 100644
> --- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> +++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> @@ -166,40 +166,6 @@ IsCpuFeatureInSetting (
>IN UINT32 Feature
>);
>
> -/**
> - Determines if a CPU feature is set in PcdCpuFeaturesCapability bit mask.
> -
> - @param[in] Feature The bit number of the CPU feature to check in the PCD
> - PcdCpuFeaturesCapability.
> -
> - @retval TRUE The CPU feature is set in PcdCpuFeaturesCapability.
> - @retval FALSE The CPU feature is not set in PcdCpuFeaturesCapability.
> -
> - @note This service could be called by BSP only.
> -**/
> -BOOLEAN
> -EFIAPI
> -IsCpuFeatureCapability (
> - IN UINT32 Feature
> - );
> -
> -/**
> - Determines if a CPU feature is set in PcdCpuFeaturesUserConfiguration bit
> mask.
> -
> - @param[in] Feature The bit number of the CPU feature to check in the PCD
> - PcdCpuFeaturesUserConfiguration.
> -
> - @retval TRUE The CPU feature is set in PcdCpuFeaturesUserConfiguration.
> - @retval FALSE The CPU feature is not set in
> PcdCpuFeaturesUserConfiguration.
> -
> - @note This service could be called by BSP only.
> -**/
> -BOOLEAN
> -EFIAPI
> -IsCpuFeatureUserConfiguration (
> - IN UINT32 Feature
> - );
> -
> /**
>Prepares for the data used by CPU feature detection and initialization.
>
> diff --git
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> index ed8d526325..3540029079 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> @@ -1242,56 +1242,6 @@ IsCpuFeatureInSetting (
> );
> }
>
> -/**
> - Determines if a CPU feature is set in PcdCpuFeaturesCapability bit mask.
> -
> - @param[in] Feature The bit number of the CPU feature to check in the PCD
> - PcdCpuFeaturesCapability
> -
> - @retval TRUE The CPU feature is set in PcdCpuFeaturesCapability.
> - @retval FALSE The CPU feature is not set in PcdCpuFeaturesCapability.
> -
> - @note This service could be called by BSP only.
> -**/
> -BOOLEAN
> -EFIAPI
> -IsCpuFeatureCapability (
> - IN UINT32 Feature
> - )
> -{
> - return IsCpuFeatureSetInCpuPcd (
> - (UINT8 *)PcdGetPtr (PcdCpuFeaturesCapability),
> - PcdGetSize (PcdCpuFeaturesCapability),
> - Feature
> - );
> -
> -}
> -
> -/**
> - Determines if a CPU feature is set in PcdCpuFeaturesUserConfiguration bit
> mask.
> -
> - @param[in] Feature The bit number of the CPU feature to check in the PCD
> - PcdCpuFeaturesUserConfiguration
> -
> - @retval TRUE The CPU feature is set in PcdCpuFeaturesUserConfiguration.
> - @retval FALSE The CPU feature is not set in
> PcdCpuFeaturesUserConfiguration.
> -
> - @note This service could be called by BSP only.
> -**/
> -BOOLEAN
> -EFIAPI
> -IsCpuFeatureUserConfiguration (
> - IN UINT32 Feature
> - )
> -{
> - return IsCpuFeatureSetInCpuPcd (
> - (UINT8 *)PcdGetPtr (PcdCpuFeaturesUserConfiguration),
> - PcdGetSize (PcdCpuFeaturesUserConfiguration),
> - Feature
> - );
> -
> -}
> -
> /**
>Switches to assigned BSP after CPU features initialization.
>
> --
> 2.15.0.windows.1
>
> ___
> 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
Re: [edk2] [Patch] BaseTools:Enable the /MP option of MSVC compiler
https://devblogs.microsoft.com/cppblog/recommendations-to-speed-c-builds-in-visual-studio/#_PCH
Bob,
Per above article, It seems /Gm needs to be removed when /MP is used.
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Feng,
> Bob C
> Sent: Friday, March 29, 2019 8:30 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming
> Subject: [edk2] [Patch] BaseTools:Enable the /MP option of MSVC compiler
>
> From: Zhiju Fan
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=1672
> The /MP option of MSVC compiler can reduce the total time to compile the
> source files on the command line.
>
> This patch is going to enable this MSVC option in BaseTools.
>
> Cc: Bob Feng
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhiju.Fan
> ---
> BaseTools/Conf/build_rule.template | 2 +-
> BaseTools/Source/Python/AutoGen/GenMake.py | 81 -
> -
> 2 files changed, 75 insertions(+), 8 deletions(-)
>
> diff --git a/BaseTools/Conf/build_rule.template
> b/BaseTools/Conf/build_rule.template
> index e56b1d9c59..e7d736740f 100755
> --- a/BaseTools/Conf/build_rule.template
> +++ b/BaseTools/Conf/build_rule.template
> @@ -127,11 +127,11 @@
>
>
> $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
>
>
> -"$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
> +"$(CC)" /MP7 /Fo${d_path}\ $(CC_FLAGS) $(INC) ${src}
>
>
> # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues
> "$(CC)" $(CC_FLAGS) -c -o ${dst} $(INC) ${src}
>
> diff --git a/BaseTools/Source/Python/AutoGen/GenMake.py
> b/BaseTools/Source/Python/AutoGen/GenMake.py
> index b441817b52..04951346ad 100644
> --- a/BaseTools/Source/Python/AutoGen/GenMake.py
> +++ b/BaseTools/Source/Python/AutoGen/GenMake.py
> @@ -433,11 +433,11 @@ cleanlib:
> self.BuildTargetList = [] # [target string]
> self.PendingBuildTargetList = []# [FileBuildRule objects]
> self.CommonFileDependency = []
> self.FileListMacros = {}
> self.ListFileMacros = {}
> -
> +self.ObjTargetDict = {}
> self.FileCache = {}
> self.LibraryBuildCommandList = []
> self.LibraryFileList = []
> self.LibraryMakefileList = []
> self.LibraryBuildDirectoryList = [] @@ -616,10 +616,15 @@ cleanlib:
> ListFileName,
> "\n".join(self.ListFileMacros[ListFileMacro]),
> False
> )
>
> +# Generate objlist used to create .obj file
> +for Type in self.ObjTargetDict:
> +NewLine = ' '.join(list(self.ObjTargetDict[Type]))
> +FileMacroList.append("OBJLIST_%s = %s" %
> + (list(self.ObjTargetDict.keys()).index(Type), NewLine))
> +
> BcTargetList = []
>
> MakefileName = self._FILE_NAME_[self._FileType]
> LibraryMakeCommandList = []
> for D in self.LibraryBuildDirectoryList:
> @@ -925,17 +930,22 @@ cleanlib:
> # Extract common files list in the dependency files
> #
> for File in DepSet:
> self.CommonFileDependency.append(self.PlaceMacro(File.Path,
> self.Macros))
>
> +CmdSumDict = {}
> +CmdTargetDict = {}
> +CmdCppDict = {}
> +DependencyDict = FileDependencyDict.copy()
> for File in FileDependencyDict:
> # skip non-C files
> if File.Ext not in [".c", ".C"] or File.Name == "AutoGen.c":
> continue
> NewDepSet = set(FileDependencyDict[File])
> NewDepSet -= DepSet
> FileDependencyDict[File] = ["$(COMMON_DEPS)"] + list(NewDepSet)
> +DependencyDict[File] = list(NewDepSet)
>
> # Convert target description object to target string in makefile
> for Type in self._AutoGenObject.Targets:
> for T in self._AutoGenObject.Targets[Type]:
> # Generate related macros if needed @@ -943,15 +953,25 @@
> cleanlib:
> self.FileListMacros[T.FileListMacro] = []
> if T.GenListFile and T.ListFileMacro not in
> self.ListFileMacros:
> self.ListFileMacros[T.ListFileMacro] = []
> if T.GenIncListFile and T.IncListFileMacro not in
> self.ListFileMacros:
> self.ListFileMacros[T.IncListFileMacro] = []
> +if self._AutoGenObject.BuildRuleFamily == TAB_COMPILER_MSFT
> and
> Type == TAB_C_CODE_FILE:
> +NewFile = self.PlaceMacro(str(T), self.Macros)
> +if self.ObjTargetDict.get(T.Target.SubDir):
> +self.ObjTargetDict[T.Target.SubDir].add(NewFile)
> +else:
> +self.ObjTargetDict[T.Target.SubDir] = set()
> +
> + self.ObjTargetDict[T.Target.SubDir].add(NewFile)
>
> Deps = []
> +
Re: [edk2] [PATCH v8] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM
Reviewed-by: Ray Ni
Sent from small device
> 在 2019年3月29日，下午11:45，Vanguput, Narendra K 写道：
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1593
>
> For every SMI occurrence, save and restore CR2 register only when SMM
> on-demand paging support is enabled in 64 bit operation mode.
> This is not a bug but to have better improvement of code.
>
> Patch5 is updated with separate functions for Save and Restore of CR2
> based on review feedback.
>
> Patch6 - Removed Global Cr2 instead used function parameter
>
> Patch7 - Removed checking Cr2 with 0 as per feedback
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vanguput Narendra K
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Yao Jiewen
> ---
> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 26 ++
> UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 9 ++---
> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 22 ++
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 30 ++
> 4 files changed, 84 insertions(+), 3 deletions(-)
>
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> index b734a1ea8c..d3f62ed806 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> @@ -316,3 +316,29 @@ SetPageTableAttributes (
>
> return ;
> }
> +
> +/**
> + This function returns with no action for 32 bit.
> +
> + @param[out] *Cr2 Pointer to variable to hold CR2 register value
> +**/
> +VOID
> +SaveCr2 (
> + UINTN *Cr2
> + )
> +{
> + return ;
> +}
> +
> +/**
> + This function returns with no action for 32 bit.
> +
> + @param[in] Cr2 Value to write into CR2 register
> +**/
> +VOID
> +RestoreCr2 (
> + UINTN Cr2
> + )
> +{
> + return ;
> +}
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 3b0b3b52ac..ce70f77709 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -1112,9 +1112,11 @@ SmiRendezvous (
> ASSERT(CpuIndex < mMaxNumberOfCpus);
>
> //
> - // Save Cr2 because Page Fault exception in SMM may override its value
> + // Save Cr2 because Page Fault exception in SMM may override its value,
> + // when using on-demand paging for above 4G memory.
> //
> - Cr2 = AsmReadCr2 ();
> + Cr2 = 0;
> + SaveCr2 ();
>
> //
> // Perform CPU specific entry hooks
> @@ -1253,10 +1255,11 @@ SmiRendezvous (
>
> Exit:
> SmmCpuFeaturesRendezvousExit (CpuIndex);
> +
> //
> // Restore Cr2
> //
> - AsmWriteCr2 (Cr2);
> + RestoreCr2 (Cr2);
> }
>
> /**
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> index 84efb22981..05e1b54ed2 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> @@ -1243,4 +1243,26 @@ EFIAPI
> PiSmmCpuSmiEntryFixupAddress (
> );
>
> +/**
> + This function reads CR2 register when on-demand paging is enabled
> + for 64 bit and no action for 32 bit.
> +
> + @param[out] *Cr2 Pointer to variable to hold CR2 register value
> +**/
> +VOID
> +SaveCr2 (
> + UINTN *Cr2
> + );
> +
> +/**
> + This function writes into CR2 register when on-demand paging is enabled
> + for 64 bit and no action for 32 bit.
> +
> + @param[in] Cr2 Value to write into CR2 register
> +**/
> +VOID
> +RestoreCr2 (
> + UINTN Cr2
> + );
> +
> #endif
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index 2c77cb47a4..e60628c080 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -1053,3 +1053,33 @@ SetPageTableAttributes (
>
> return ;
> }
> +
> +/**
> + This function reads CR2 register when on-demand paging is enabled
> +
> + @param[out] *Cr2 Pointer to variable to hold CR2 register value
> +**/
> +VOID
> +SaveCr2 (
> + UINTN *Cr2
> + )
> +{
> + if (!mCpuSmmStaticPageTable) {
> +*Cr2 = AsmReadCr2 ();
> + }
> +}
> +
> +/**
> + This function restores CR2 register when on-demand paging is enabled
> +
> + @param[in] Cr2 Value to write into CR2 register
> +**/
> +VOID
> +RestoreCr2 (
> + UINTN Cr2
> + )
> +{
> + if (!mCpuSmmStaticPageTable) {
> +AsmWriteCr2 (Cr2);
> + }
> +}
> --
> 2.16.2.windows.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v6] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM
Yes. With below "Cr2 !=0" removed from final commit, Reviewed-by: Ray Ni
> > +RestoreCr2 (
> > + UINTN Cr2
> > + )
> > +{
> > + if ((!mCpuSmmStaticPageTable) && (Cr2 != 0)) {
> > +AsmWriteCr2 (Cr2);
> > + }
> > +}
> -Original Message-
> From: Vanguput, Narendra K
> Sent: Friday, March 29, 2019 5:32 PM
> To: Ni, Ray ; edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric ;
> Laszlo Ersek
> Subject: RE: [edk2] [PATCH v6] UefiCpuPkg\CpuSmm: Save & restore CR2 on-
> demand paging in SMM
>
> Hi Ray,
>
> While programming, I thought this cannot be 0 as in SDM, it says page-fault
> linear address.
> >> CR2 - Contains the page-fault linear address (the linear address that
> caused a page fault).
>
> So added a check for 0.
>
> Now as the function is changed like program into CR2 register based on input
> parameter and checking for 0 is up to caller of this function. And also we
> don't need to require for checking 0 means, will remove it. Please confirm.
>
> Thanks,
> Naren
>
> -Original Message-
> From: Ni, Ray
> Sent: Friday, March 29, 2019 10:40 AM
> To: Vanguput, Narendra K ; edk2-
> de...@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric ;
> Laszlo Ersek
> Subject: RE: [edk2] [PATCH v6] UefiCpuPkg\CpuSmm: Save & restore CR2 on-
> demand paging in SMM
>
> > + if ((!mCpuSmmStaticPageTable) && (Cr2 != 0)) {
>
> Can the "Cr2 != 0" be removed?
>
> > -Original Message-
> > From: edk2-devel On Behalf Of
> > nkvangup
> > Sent: Friday, March 29, 2019 12:58 PM
> > To: edk2-devel@lists.01.org
> > Cc: Yao, Jiewen ; Dong, Eric
> > ; Laszlo Ersek
> > Subject: [edk2] [PATCH v6] UefiCpuPkg\CpuSmm: Save & restore CR2 on-
> > demand paging in SMM
> >
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1593
> >
> > For every SMI occurrence, save and restore CR2 register only when SMM
> > on- demand paging support is enabled in 64 bit operation mode.
> > This is not a bug but to have better improvement of code.
> >
> > Patch5 is updated with separate functions for Save and Restore of CR2
> > based on review feedback.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Vanguput Narendra K
> > Cc: Eric Dong
> > Cc: Ray Ni
> > Cc: Laszlo Ersek
> > Cc: Yao Jiewen
> > ---
> > UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 26
> > ++
> > UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 9 ++---
> > UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 22
> > ++
> > UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 30
> > ++
> > 4 files changed, 84 insertions(+), 3 deletions(-)
> >
> > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> > b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> > index b734a1ea8c..af96e42982 100644
> > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> > @@ -316,3 +316,29 @@ SetPageTableAttributes (
> >
> >return ;
> > }
> > +
> > +/**
> > + This function returns with no action for 32 bit.
> > +
> > + @param[in] *Cr2 Pointer to variable to hold CR2 register value
> > +**/ VOID
> > +SaveCr2 (
> > + UINTN *Cr2
> > + )
> > +{
> > + return ;
> > +}
> > +
> > +/**
> > + This function returns with no action for 32 bit.
> > +
> > + @param[in] Cr2 Value to write into CR2 register **/ VOID
> > +RestoreCr2 (
> > + UINTN Cr2
> > + )
> > +{
> > + return ;
> > +}
> > diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > index 3b0b3b52ac..ce70f77709 100644
> > --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> > @@ -1112,9 +1112,11 @@ SmiRendezvous (
> >ASSERT(CpuIndex < mMaxNumberOfCpus);
> >
> >//
> > - // Save Cr2 because Page Fault exception in SMM may override its
> > value
> > + // Save Cr2 because Page Fault exception in SMM may override its
> > + value, // when using on-demand paging for above 4G memory.
> >//
> > - Cr2 = AsmReadCr2 ();
> > + Cr2 = 0;
> > + SaveCr2 ();
> >
> >//
> >// Perform CPU specific entry hooks @@ -1253,10 +1255,11 @@
> > SmiRendezvous (
> >
> > Exit:
> >SmmCpuFeaturesRendezvousExit (CpuIndex);
> > +
&
Re: [edk2] [PATCH] UefiPayloadPkg: Enhance UEFI payload for coreboot and Slim Bootloader
Guo, Just to double confirm: UefiPayloadPkg will not require Legacy8254 timer support. The old packages Coreboot*Pkgs will be removed. Which means now only QEMU/OVMF needs the Legacy8254 support. Laszlo, Now since QEMU/OVMF is the only consumer of the Legacy8254 driver, do you agree that the Legacy8254 is moved to OvmfPkg? Note: We agreed that Legacy8259 will be moved to OvmfPkg/Csm directory and that decision is not going to be changed by this new situation. Thanks, Ray > -Original Message- > From: edk2-devel On Behalf Of Guo > Dong > Sent: Friday, March 29, 2019 8:34 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH] UefiPayloadPkg: Enhance UEFI payload for coreboot > and Slim Bootloader > > CorebootModulePkg and CorebootPayloadPkg originally supports coreboot > only. > In order to support other bootloaders, such as Slim Bootloader, they need > be updated to be more generic. > UEFI Payload (UefiPayloadPkg) a converged package from > CorebootModulePkg > and CorebootPayloadPkg with following updates: > a. Support both coreboot and Slim Bootloader > b. Removed SataControllerDxe and BaseSerialPortLib16550 to use EDK2 > modules > c. Support passing bootloader parameter to UEFI payload, e.g. coreboot >table from coreboot or HOB list from Slim Bootloader > d. Using GraphicsOutputDxe from EDK2 with minor change instead of FbGop > e. Remove the dependency to IntelFrameworkPkg and > IntelFrameworkModulePkg >and QuarkSocPkg > f. Use BaseDebugLibSerialPort library as DebugLib > g. Use HPET timer, drop legacy 8254 timer support > h. Use BaseXApicX2ApicLib instead of BaseXApicLib > i. Other clean ups > > On how UefiPayloadPkg could work with coreboot/Slim Bootloader, please > refer UefiPayloadPkg/BuildAndIntegrationInstructions.txt > > Once UefiPayloadPkg is checked-in, CorebootModulePkg and > CorebootPayloadPkg > could be retired. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Guo Dong ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v6] UefiCpuPkg\CpuSmm: Save & restore CR2 on-demand paging in SMM
> + if ((!mCpuSmmStaticPageTable) && (Cr2 != 0)) {
Can the "Cr2 != 0" be removed?
> -Original Message-
> From: edk2-devel On Behalf Of
> nkvangup
> Sent: Friday, March 29, 2019 12:58 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Dong, Eric ;
> Laszlo Ersek
> Subject: [edk2] [PATCH v6] UefiCpuPkg\CpuSmm: Save & restore CR2 on-
> demand paging in SMM
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1593
>
> For every SMI occurrence, save and restore CR2 register only when SMM on-
> demand paging support is enabled in 64 bit operation mode.
> This is not a bug but to have better improvement of code.
>
> Patch5 is updated with separate functions for Save and Restore of CR2 based
> on review feedback.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vanguput Narendra K
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Cc: Yao Jiewen
> ---
> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 26
> ++
> UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 9 ++---
> UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 22
> ++
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c| 30
> ++
> 4 files changed, 84 insertions(+), 3 deletions(-)
>
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> index b734a1ea8c..af96e42982 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> @@ -316,3 +316,29 @@ SetPageTableAttributes (
>
>return ;
> }
> +
> +/**
> + This function returns with no action for 32 bit.
> +
> + @param[in] *Cr2 Pointer to variable to hold CR2 register value **/
> +VOID
> +SaveCr2 (
> + UINTN *Cr2
> + )
> +{
> + return ;
> +}
> +
> +/**
> + This function returns with no action for 32 bit.
> +
> + @param[in] Cr2 Value to write into CR2 register **/ VOID
> +RestoreCr2 (
> + UINTN Cr2
> + )
> +{
> + return ;
> +}
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 3b0b3b52ac..ce70f77709 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -1112,9 +1112,11 @@ SmiRendezvous (
>ASSERT(CpuIndex < mMaxNumberOfCpus);
>
>//
> - // Save Cr2 because Page Fault exception in SMM may override its value
> + // Save Cr2 because Page Fault exception in SMM may override its
> + value, // when using on-demand paging for above 4G memory.
>//
> - Cr2 = AsmReadCr2 ();
> + Cr2 = 0;
> + SaveCr2 ();
>
>//
>// Perform CPU specific entry hooks
> @@ -1253,10 +1255,11 @@ SmiRendezvous (
>
> Exit:
>SmmCpuFeaturesRendezvousExit (CpuIndex);
> +
>//
>// Restore Cr2
>//
> - AsmWriteCr2 (Cr2);
> + RestoreCr2 (Cr2);
> }
>
> /**
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> index 84efb22981..c9d147c8a1 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h
> @@ -1243,4 +1243,26 @@ EFIAPI
> PiSmmCpuSmiEntryFixupAddress (
> );
>
> +/**
> + This function reads CR2 register when on-demand paging is enabled
> + for 64 bit and no action for 32 bit.
> +
> + @param[in] *Cr2 Pointer to variable to hold CR2 register value **/
> +VOID
> +SaveCr2 (
> + UINTN *Cr2
> + );
> +
> +/**
> + This function writes into CR2 register when on-demand paging is
> +enabled
> + for 64 bit and no action for 32 bit.
> +
> + @param[in] Cr2 Value to write into CR2 register **/ VOID
> +RestoreCr2 (
> + UINTN Cr2
> + );
> +
> #endif
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index 2c77cb47a4..6cb44fbbe5 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -1053,3 +1053,33 @@ SetPageTableAttributes (
>
>return ;
> }
> +
> +/**
> + This function reads CR2 register when on-demand paging is enabled
> +
> + @param[in] *Cr2 Pointer to variable to hold CR2 register value **/
> +VOID
> +SaveCr2 (
> + UINTN *Cr2
> + )
> +{
> + if (!mCpuSmmStaticPageTable) {
> +*Cr2 = AsmReadCr2 ();
> + }
> +}
> +
> +/**
> + This function restores CR2 register when on-demand paging is enabled
> +
> + @param[in] Cr2 Value to write into CR2 register **/ VOID
> +RestoreCr2 (
> + UINTN Cr2
> + )
> +{
> + if ((!mCpuSmmStaticPageTable) && (Cr2 != 0)) {
> +AsmWriteCr2 (Cr2);
> + }
> +}
> --
> 2.16.2.windows.1
>
> ___
> 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
Re: [edk2] [PATCH 3/4] ShellPkg/UefiHandleParsingLib: Remove some unused Guids
Reviewed-by: Ray Ni
> -Original Message-
> From: Zhang, Shenglei
> Sent: Friday, March 29, 2019 9:41 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Ni, Ray
> Subject: [PATCH 3/4] ShellPkg/UefiHandleParsingLib: Remove some unused
> Guids
>
> ExtendedSalBootService.h, ExtendedSalServiceClasses.h and McaInitPmi.h will
> be deleted. So remove the Guids defined in these Protocols. And also remove
> strings in uni file.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1560
>
> Cc: Jaben Carsey
> Cc: Ray Ni
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> ---
> .../UefiHandleParsingLib/UefiHandleParsingLib.c | 17 -
> .../UefiHandleParsingLib.inf| 17 -
> .../UefiHandleParsingLib.uni| 17 -
> 3 files changed, 51 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> index 2d94a52108..a106c0906c 100644
> --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.c
> @@ -2321,23 +2321,6 @@ STATIC CONST GUID_INFO_BLOCK mGuidStringList[]
> = {
>{STRING_TOKEN(STR_FVB2),
> ,NULL},
>{STRING_TOKEN(STR_CPUIO2),,
> NULL},
>{STRING_TOKEN(STR_LEGACY_R2), ,
> NULL},
> - {STRING_TOKEN(STR_SAL_MIP), ,
> NULL},
> - {STRING_TOKEN(STR_ES_BS),
> , NULL},
> - {STRING_TOKEN(STR_ES_BIO),
> , NULL},
> - {STRING_TOKEN(STR_ES_STALL),
> ,NULL},
> - {STRING_TOKEN(STR_ES_RTC),
> , NULL},
> - {STRING_TOKEN(STR_ES_VS),
> , NULL},
> - {STRING_TOKEN(STR_ES_MTC),
> , NULL},
> - {STRING_TOKEN(STR_ES_RESET),
> ,NULL},
> - {STRING_TOKEN(STR_ES_SC),
> , NULL},
> - {STRING_TOKEN(STR_ES_FBS),
> , NULL},
> - {STRING_TOKEN(STR_ES_MP),
> , NULL},
> - {STRING_TOKEN(STR_ES_PAL),
> , NULL},
> - {STRING_TOKEN(STR_ES_BASE),
> , NULL},
> - {STRING_TOKEN(STR_ES_MCA),
> , NULL},
> - {STRING_TOKEN(STR_ES_PCI),
> , NULL},
> - {STRING_TOKEN(STR_ES_CACHE),
> ,NULL},
> - {STRING_TOKEN(STR_ES_MCA_LOG),
> , NULL},
>{STRING_TOKEN(STR_S2ARCH),,
> NULL},
>{STRING_TOKEN(STR_EODXE), ,
> NULL},
>{STRING_TOKEN(STR_ISAHC), ,
> NULL},
> diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> index a795fb92de..edab57f892 100644
> --- a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> +++ b/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> @@ -234,23 +234,6 @@
>gEfiFirmwareVolumeBlock2ProtocolGuid## UNDEFINED
>gEfiCpuIo2ProtocolGuid ## UNDEFINED
>gEfiLegacyRegion2ProtocolGuid ## UNDEFINED
> - gEfiSalMcaInitPmiProtocolGuid ## UNDEFINED
> - gEfiExtendedSalBootServiceProtocolGuid ## UNDEFINED
> - gEfiExtendedSalBaseIoServicesProtocolGuid ## UNDEFINED
> - gEfiExtendedSalStallServicesProtocolGuid## UNDEFINED
> - gEfiExtendedSalRtcServicesProtocolGuid ## UNDEFINED
> - gEfiExtendedSalVariableServicesProtocolGuid ## UNDEFINED
> - gEfiExtendedSalMtcServicesProtocolGuid ## UNDEFINED
> - gEfiExtendedSalResetServicesProtocolGuid## UNDEFINED
> - gEfiExtendedSalStatusCodeServicesProtocolGuid ## UNDEFINED
> - gEfiExtendedSalFvBlockServicesProtocolGuid ## UNDEFINED
> - gEfiExtendedSalMpServicesProtocolGuid ## UNDEFINED
> - gEfiExtendedSalPalServicesProtocolGuid ## UNDEFINED
> - gEfiExtendedSalBaseServicesProtocolGuid ## UNDEFINED
> - gEfiExtendedSalMcaServicesProtocolGuid ## UNDEFINED
> - gEfiExtendedSalPciServicesProtocolGuid ## UNDEFINED
> - gEfiExtendedSalCacheServicesProtocolGuid## UNDEFINED
> - gEfiExtendedSalMcaLogServicesProtocolGuid ## UNDEFINED
>gEfiSecurity2ArchProtocolGuid ## UNDEFINED
>gEfiSmmEndOfDxeProtocolGuid ## UNDEFINED
>gEfiIsaHcProtocolGuid ## UNDEFINED
> diff --git a/ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.uni
> b/ShellPkg/Library/UefiHandleParsingLib/Uefi
Re: [edk2] [PATCH 2/4] ShellPkg/UefiShellDebug1CommandsLib
Reviewed-by: Ray Ni
> -Original Message-
> From: Zhang, Shenglei
> Sent: Friday, March 29, 2019 9:41 AM
> To: edk2-devel@lists.01.org
> Cc: Carsey, Jaben ; Ni, Ray
> Subject: [PATCH 2/4] ShellPkg/UefiShellDebug1CommandsLib
>
> With Itanium architecture unsupported, gEfiSalSystemTableGuid and
> gEfiMpsTableGuid will be no longer used.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1560
>
> Cc: Jaben Carsey
> Cc: Ray Ni
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> ---
> ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c | 10 --
> .../UefiShellDebug1CommandsLib.inf | 2 --
> 2 files changed, 12 deletions(-)
>
> diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
> index a4c18c9b68..023806742d 100644
> --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
> +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
> @@ -17,9 +17,7 @@
> #include "UefiShellDebug1CommandsLib.h"
> #include
> #include
> -#include
> #include
> -#include
>
> /**
>Make a printable character.
> @@ -186,10 +184,6 @@ ShellCommandRunDmem (
>AcpiTableAddress = (UINT64)(UINTN)gST-
> >ConfigurationTable[TableWalker].VendorTable;
>continue;
> }
> -if (CompareGuid(>ConfigurationTable[TableWalker].VendorGuid,
> )) {
> - SalTableAddress = (UINT64)(UINTN)gST-
> >ConfigurationTable[TableWalker].VendorTable;
> - continue;
> -}
> if (CompareGuid(>ConfigurationTable[TableWalker].VendorGuid,
> )) {
>SmbiosTableAddress = (UINT64)(UINTN)gST-
> >ConfigurationTable[TableWalker].VendorTable;
>continue;
> @@ -198,10 +192,6 @@ ShellCommandRunDmem (
>SmbiosTableAddress = (UINT64) (UINTN) gST-
> >ConfigurationTable[TableWalker].VendorTable;
>continue;
> }
> -if (CompareGuid(>ConfigurationTable[TableWalker].VendorGuid,
> )) {
> - MpsTableAddress = (UINT64)(UINTN)gST-
> >ConfigurationTable[TableWalker].VendorTable;
> - continue;
> -}
>}
>
>ShellPrintHiiEx(-1, -1, NULL, STRING_TOKEN (STR_DMEM_SYSTEM_TABLE),
> gShellDebug1HiiHandle, diff --git
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
> b.inf
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
> b.inf
> index ec1f87ae19..f2666b7ff9 100644
> ---
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLi
> b.inf
> +++
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Command
> +++ sLib.inf
> @@ -130,8 +130,6 @@
>gEfiGlobalVariableGuid ## SOMETIMES_CONSUMES ## GUID
>gEfiSmbiosTableGuid ## SOMETIMES_CONSUMES ## SystemTable
>gEfiSmbios3TableGuid## SOMETIMES_CONSUMES ## SystemTable
> - gEfiMpsTableGuid## SOMETIMES_CONSUMES ## SystemTable
> - gEfiSalSystemTableGuid ## SOMETIMES_CONSUMES ## SystemTable
>gEfiAcpi10TableGuid ## SOMETIMES_CONSUMES ## SystemTable
>gEfiAcpi20TableGuid ## SOMETIMES_CONSUMES ## SystemTable
>gShellDebug1HiiGuid ## SOMETIMES_CONSUMES ## HII
> --
> 2.18.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V5 14/17] MdeModulePkg: Add definitions for EDKII DEBUG PPI
Zhichao,
I see you added library API called DebugVPrint. Why the interface in the PPI is
called DebugBPrint?
What does "B" stand for? Why invent a "B" but not use "V"?
> -Original Message-
> From: Gao, Zhichao
> Sent: Thursday, March 28, 2019 4:10 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray ; Zeng, Star ; Gao, Liming
> ; Sean Brogan ;
> Michael Turner ; Bret Barkelew
>
> Subject: [PATCH V5 14/17] MdeModulePkg: Add definitions for EDKII DEBUG
> PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1549
>
> Add a debug PPI for PEI phase. This PPI will provide basic services of debug.
> PEI debug lib instance can use these services to implement debug function to
> reduce the PEIMs which consume the debug lib.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> Reviewed-by: Hao Wu
> ---
> MdeModulePkg/Include/Ppi/Debug.h | 82
>
> MdeModulePkg/MdeModulePkg.dec| 3 ++
> 2 files changed, 85 insertions(+)
> create mode 100644 MdeModulePkg/Include/Ppi/Debug.h
>
> diff --git a/MdeModulePkg/Include/Ppi/Debug.h
> b/MdeModulePkg/Include/Ppi/Debug.h
> new file mode 100644
> index 00..0fb6a8fdc2
> --- /dev/null
> +++ b/MdeModulePkg/Include/Ppi/Debug.h
> @@ -0,0 +1,82 @@
> +/** @file
> + Define the EDKII_DEBUG_PPI that PEIMs can use to dump info to debug
> port.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + This program and the accompanying materials are licensed and made
> + available under the terms and conditions of the BSD License which
> + accompanies this distribution. The full text of the license may be
> + found at http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __EDKII_DEBUG_PPI_H__
> +#define __EDKII_DEBUG_PPI_H__
> +
> +#include
> +
> +//
> +// Global ID for the EDKII_DEBUG_PPI
> +//
> +#define EDKII_DEBUG_PPI_GUID \
> + { \
> +0x999e699c, 0xb013, 0x475e, {0xb1, 0x7b, 0xf3, 0xa8, 0xae, 0x5c,
> +0x48, 0x75} \
> + }
> +
> +///
> +/// Forward declaration for the PEI_DEBUG_LIB_DEBUG_PPI
> EDKII_DEBUG_PPI
> +/// typedef struct _EDKII_DEBUG_PPI EDKII_DEBUG_PPI;
> +
> +/**
> + Print a debug message to debug output device if the specified error
> +level
> + is enabled.
> +
> + @param[in] ErrorLevel The error level of the debug message.
> + @param[in] Format Format string for the debug message to
> print.
> + @param[in] Marker BASE_LIST marker for the variable
> argument
> list.
> +
> +**/
> +typedef
> +VOID
> +(EFIAPI *EDKII_DEBUG_BPRINT)(
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8*Format,
> + IN BASE_LIST Marker
> + );
> +
> +/**
> + Print an assert message containing a filename, line number, and
> description.
> + This may be followed by a breakpoint or a dead loop.
> +
> + @param[in] FileName The pointer to the name of the source
> file
> that
> + generated the assert condition.
> + @param[in] LineNumber The line number in the source file that
> generated
> + the assert condition
> + @param[in] Description The pointer to the description of the
> assert
> condition.
> +
> +**/
> +typedef
> +VOID
> +(EFIAPI *EDKII_DEBUG_ASSERT)(
> + IN CONST CHAR8*FileName,
> + IN UINTN LineNumber,
> + IN CONST CHAR8*Description
> + );
> +
> +///
> +/// This PPI contains a set of services to print message to debug
> +output device /// struct _EDKII_DEBUG_PPI {
> + EDKII_DEBUG_BPRINTDebugBPrint;
> + EDKII_DEBUG_ASSERTDebugAssert;
> +};
> +
> +extern EFI_GUID gEdkiiDebugPpiGuid;
> +
> +#endif
> +
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec index a2130bc439..9bbd0572f5
> 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -492,6 +492,9 @@
>## Include/Ppi/AtaPassThru.h
>gEdkiiPeiAtaPa
Re: [edk2] [PATCH V5 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI debug lib
Zhichao,
For a PEIM, it may not be proper to have a global variable and update that
global variable during execution.
Because sometimes the PEIM runs from read-only SPI flash, the global variable
cannot be updated.
I see you have a check against NULL when using that global variable. How about
just remove the global variable and always locate the PPI?
> -Original Message-
> From: Gao, Zhichao
> Sent: Thursday, March 28, 2019 4:10 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Wang, Jian J
> ; Wu, Hao A ; Ni, Ray
> ; Zeng, Star ; Sean Brogan
> ; Michael Turner
> ; Bret Barkelew
>
> Subject: [PATCH V5 16/17] MdeModulePkg/PeiDebugLibDebugPpi: Add PEI
> debug lib
>
> From: Liming Gao
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1549
>
> Add a PEI debug library instance PeiDebugLibDebugPpi base on DebugPpi.
> Using the combination of the DebugServicePei and this lib instance can
> reduce the image size of PEI drivers.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> Reviewed-by: Hao Wu
> ---
> .../Library/PeiDebugLibDebugPpi/DebugLib.c| 456 ++
> .../PeiDebugLibDebugPpi.inf | 56 +++
> 2 files changed, 512 insertions(+)
> create mode 100644
> MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> create mode 100644
> MdeModulePkg/Library/PeiDebugLibDebugPpi/PeiDebugLibDebugPpi.inf
>
> diff --git a/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> new file mode 100644
> index 00..349577e5ea
> --- /dev/null
> +++ b/MdeModulePkg/Library/PeiDebugLibDebugPpi/DebugLib.c
> @@ -0,0 +1,456 @@
> +/** @file
> + PEI debug lib instance base on DebugPpi to save size
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + This program and the accompanying materials are licensed and made
> + available under the terms and conditions of the BSD License which
> + accompanies this distribution. The full text of the license may be
> + found at http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +EDKII_DEBUG_PPI *mEdkiiDebugPpi = NULL;
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib
> + function GetDebugPrintErrorLevel (), then print the message specified
> + by Format and the associated variable argument list to the debug output
> device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevelThe error level of the debug message.
> + @param FormatFormat string for the debug message to print.
> + @param ... Variable argument list whose contents are accessed
> +based on the format string specified by Format.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugPrint (
> + IN UINTNErrorLevel,
> + IN CONST CHAR8 *Format,
> + ...
> + )
> +{
> + VA_LIST Marker;
> +
> + VA_START (Marker, Format);
> + DebugVPrint (ErrorLevel, Format, Marker);
> + VA_END (Marker);
> +}
> +
> +
> +/**
> + Prints a debug message to the debug output device if the specified
> + error level is enabled.
> + This function use BASE_LIST which would provide a more compatible
> + service than VA_LIST.
> +
> + If any bit in ErrorLevel is also set in DebugPrintErrorLevelLib
> + function GetDebugPrintErrorLevel (), then print the message specified
> + by Format and the associated variable argument list to the debug output
> device.
> +
> + If Format is NULL, then ASSERT().
> +
> + @param ErrorLevel The error level of the debug message.
> + @param Format Format string for the debug message to print.
> + @param BaseListMarker BASE_LIST marker for the variable argument list.
> +
> +**/
> +VOID
> +EFIAPI
> +DebugBPrint (
> + IN UINTN ErrorLevel,
> + IN CONST CHAR8 *Format,
> + IN BASE_LIST BaseListMarker
> + )
> +{
> + EFI_STATUS Status;
> +
> + //
> + // If Format is NULL, then ASSERT().
> + //
> + ASSERT (Format != NULL);
> +
> +
Re: [edk2] [PATCH 0/2] Fix bugs in HiiDatabase driver
Thanks for the comments. Sent out V2 with correct patch subject. > -Original Message- > From: Wu, Hao A > Sent: Friday, March 8, 2019 10:22 AM > To: Ni, Ray ; edk2-devel@lists.01.org > Subject: RE: [edk2] [PATCH 0/2] Fix bugs in HiiDatabase driver > > Quick comment, please add the CVE number in the patch subject. > > Liming has already documented the new rule for this kind of fix: > https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message- > Format > > Best Regards, > Hao Wu > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Ray Ni > > Sent: Friday, March 08, 2019 10:21 AM > > To: edk2-devel@lists.01.org > > Subject: [edk2] [PATCH 0/2] Fix bugs in HiiDatabase driver > > > > Ray Ni (2): > > MdeModulePkg/HiiDatabase: Fix potential integer overflow > > MdeModulePkg/HiiImage: Fix stack overflow when corrupted BMP is > > parsed > > > > MdeModulePkg/Universal/HiiDatabaseDxe/Image.c | 130 > > ++ > > 1 file changed, 105 insertions(+), 25 deletions(-) > > > > -- > > 2.20.1.windows.1 > > > > ___ > > 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
Re: [edk2] Does ARM platform produce MP protocol?
> -Original Message-
> From: edk2-devel On Behalf Of Ard
> Biesheuvel
> Sent: Wednesday, March 6, 2019 3:38 PM
> To: Ni, Ray
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Does ARM platform produce MP protocol?
>
> On Wed, 6 Mar 2019 at 06:44, Ni, Ray wrote:
> >
> > Ard, Leif,
> > I am a bit interested in how ARM platform supports the MP?
> > PI Spec defines below protocol but I failed to find a driver in ARM platform
> producing this protocol.
> > Or did I miss anything?
> >
>
> No you are right. We don't expose that on ARM, since UEFI only runs on a
> single core. Bringing up and taking down cores is done via a protocol called
> PSCI, which is implemented by firmware running at a higher privilege level.
>
> So while it would be possible to implement the MP protocol on top of PSCI,
> we haven't identified a use case for it yet. (The OS calls PSCI directly to
> boot
> the secondary cores)
Is below EFI_MM_MP_PROTOCOL (added in PI spec 1.6) implemented in ARM?
Or will it be implemented by an ARM module?
I am asking this because MP_SERVICES protocol exposes CPU location information
(Package/Core/Thread) through *GetProcessorInfo*, but MM_MP protocol doesn't
have a way to expose that information.
If such location information isn't exposed by MM_MP, is that because ARM doesn't
care about the location information? Or because ARM cares but forgot to add
similar
*GetProcessorInfo* interface to MM_MP when changing the PI spec?
Or ARM doesn't use the MM_MP at all?
typedef struct _EFI_MM_MP_PROTOCOL {
UINT32 Revision,
UINT32 Attributes,
EFI_MM_ GET_NUMBER_OF_PROCESSORS GetNumberOfProcessors,
EFI_MM_DISPATCH_PROCEDUREDispatchProcedure,
EFI_MM_BROADCAST_PROCEDURE BroadcastProcedure,
EFI_MM_SET_STARTUP_PROCEDURE SetStartupProcedure,
EFI_CHECK_FOR_PROCEDURE CheckOnProcedure,
EFI_WAIT_FOR_PROCEDURE WaitForProcedure,
}EFI_MM_MP_PROTOCOL;
>
> > typedef struct _EFI_MP_SERVICES_PROTOCOL {
> > EFI_MP_SERVICES_GET_NUMBER_OF_PROCESSORS
> GetNumberOfProcessors;
> > EFI_MP_SERVICES_GET_PROCESSOR_INFO GetProcessorInfo;
> > EFI_MP_SERVICES_STARTUP_ALL_APS StartupAllAPs;
> > EFI_MP_SERVICES_STARTUP_THIS_AP StartupThisAP;
> > EFI_MP_SERVICES_SWITCH_BSP SwitchBSP;
> EFI_MP_SERVICES_ENABLEDISABLEAP
> > EnableDisableAP; EFI_MP_SERVICES_WHOAMI WhoAmI; }
> > EFI_MP_SERVICES_PROTOCOL;
> >
> > Thanks,
> > Ray
> ___
> 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
Re: [edk2] [PATCH] UefiCpuPkg/Microcode.c: Add verification before calculate CheckSum32
Pushed @ 219e560c20034843ac9917146c60db99bd01b6f4.
> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, March 6, 2019 1:38 PM
> To: Ni, Ray ; edk2-devel@lists.01.org
> Cc: Dong, Eric ; Chen, Chen A
>
> Subject: RE: [edk2] [PATCH] UefiCpuPkg/Microcode.c: Add verification
> before calculate CheckSum32
>
> This is a bug. I agree to add it into Q1 stable tag.
>
> Thanks
> Liming
> > -Original Message-
> > From: Ni, Ray
> > Sent: Tuesday, March 5, 2019 9:35 PM
> > To: edk2-devel@lists.01.org; Gao, Liming
> > Cc: Dong, Eric ; Ni, Ray ;
> > Chen, Chen A
> > Subject: RE: [edk2] [PATCH] UefiCpuPkg/Microcode.c: Add verification
> > before calculate CheckSum32
> >
> > Liming,
> > Do I need any approval from you side before pushing the commit?
> >
> > Thanks,
> > Ray
> >
> > > -Original Message-
> > > From: edk2-devel On Behalf Of Ni,
> > > Ray
> > > Sent: Wednesday, March 6, 2019 10:15 AM
> > > To: Chen, Chen A ; edk2-devel@lists.01.org
> > > Cc: Dong, Eric
> > > Subject: Re: [edk2] [PATCH] UefiCpuPkg/Microcode.c: Add verification
> > > before calculate CheckSum32
> > >
> > > Reviewed-by: Ray Ni
> > >
> > > > -Original Message-
> > > > From: edk2-devel On Behalf Of
> > > > Chen A Chen
> > > > Sent: Tuesday, March 5, 2019 8:21 AM
> > > > To: edk2-devel@lists.01.org
> > > > Cc: Dong, Eric
> > > > Subject: [edk2] [PATCH] UefiCpuPkg/Microcode.c: Add verification
> > > > before calculate CheckSum32
> > > >
> > > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1020
> > > >
> > > > Should make sure the TotalSize of Microcode is aligned with 4
> > > > bytes before calling CalculateSum32 function.
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Chen A Chen
> > > > Cc: Ray Ni
> > > > Cc: Eric Dong
> > > > ---
> > > > UefiCpuPkg/Library/MpInitLib/Microcode.c | 31
> > > --
> > > > -
> > > > 1 file changed, 20 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> > > > b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> > > > index 5f9ae22794..643a6f94f4 100644
> > > > --- a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> > > > +++ b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> > > > @@ -166,20 +166,29 @@ MicrocodeDetect (
> > > > //
> > > > CorrectMicrocode = FALSE;
> > > >
> > > > -//
> > > > -// Save an in-complete CheckSum32 from CheckSum Part1 for
> common
> > > > parts.
> > > > -//
> > > > if (MicrocodeEntryPoint->DataSize == 0) {
> > > > - InCompleteCheckSum32 = CalculateSum32 (
> > > > - (UINT32 *) MicrocodeEntryPoint,
> > > > - sizeof (CPU_MICROCODE_HEADER) + 2000
> > > > - );
> > > > + TotalSize = sizeof (CPU_MICROCODE_HEADER) + 2000;
> > > > } else {
> > > > - InCompleteCheckSum32 = CalculateSum32 (
> > > > - (UINT32 *) MicrocodeEntryPoint,
> > > > - sizeof (CPU_MICROCODE_HEADER) +
> > > MicrocodeEntryPoint-
> > > > >DataSize
> > > > - );
> > > > + TotalSize = sizeof (CPU_MICROCODE_HEADER) +
> > > > + MicrocodeEntryPoint-
> > > > >DataSize;
> > > > }
> > > > +
> > > > +///
> > > > +/// Check overflow and whether TotalSize is aligned with 4 bytes.
> > > > +///
> > > > +if ( ((UINTN)MicrocodeEntryPoint + TotalSize) > MicrocodeEnd ||
> > > > + (TotalSize & 0x3) != 0
> > > > + ) {
> > > > + MicrocodeEntryPoint = (CPU_MICROCODE_HEADER *) (((UINTN)
> > > > MicrocodeEntryPoint) + SIZE_1KB);
> > > > + continue;
> > > > +}
> > > > +
> > > > +//
> > > > +// Save an in-complete CheckSum32 from CheckSum Part1 for
> > > > + common
> > > > parts.
> > > > +//
> > > > +InCompleteCheckSum32 = CalculateSum32 (
> > > > + (UINT32 *) MicrocodeEntryPoint,
> > > > + TotalSize
> > > > + );
> > > > InCompleteCheckSum32 -= MicrocodeEntryPoint-
> > > > >ProcessorSignature.Uint32;
> > > > InCompleteCheckSum32 -= MicrocodeEntryPoint->ProcessorFlags;
> > > > InCompleteCheckSum32 -= MicrocodeEntryPoint->Checksum;
> > > > --
> > > > 2.16.2.windows.1
> > > >
> > > > ___
> > > > 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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] Does ARM platform produce MP protocol?
Ard, Leif,
I am a bit interested in how ARM platform supports the MP?
PI Spec defines below protocol but I failed to find a driver in ARM platform
producing this protocol.
Or did I miss anything?
typedef struct _EFI_MP_SERVICES_PROTOCOL {
EFI_MP_SERVICES_GET_NUMBER_OF_PROCESSORS GetNumberOfProcessors;
EFI_MP_SERVICES_GET_PROCESSOR_INFO GetProcessorInfo;
EFI_MP_SERVICES_STARTUP_ALL_APS StartupAllAPs;
EFI_MP_SERVICES_STARTUP_THIS_AP StartupThisAP;
EFI_MP_SERVICES_SWITCH_BSP SwitchBSP;
EFI_MP_SERVICES_ENABLEDISABLEAP EnableDisableAP;
EFI_MP_SERVICES_WHOAMI WhoAmI;
} EFI_MP_SERVICES_PROTOCOL;
Thanks,
Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] UefiCpuPkg/Microcode.c: Add verification before calculate CheckSum32
Liming,
Do I need any approval from you side before pushing the commit?
Thanks,
Ray
> -Original Message-
> From: edk2-devel On Behalf Of Ni, Ray
> Sent: Wednesday, March 6, 2019 10:15 AM
> To: Chen, Chen A ; edk2-devel@lists.01.org
> Cc: Dong, Eric
> Subject: Re: [edk2] [PATCH] UefiCpuPkg/Microcode.c: Add verification
> before calculate CheckSum32
>
> Reviewed-by: Ray Ni
>
> > -Original Message-
> > From: edk2-devel On Behalf Of Chen A
> > Chen
> > Sent: Tuesday, March 5, 2019 8:21 AM
> > To: edk2-devel@lists.01.org
> > Cc: Dong, Eric
> > Subject: [edk2] [PATCH] UefiCpuPkg/Microcode.c: Add verification
> > before calculate CheckSum32
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1020
> >
> > Should make sure the TotalSize of Microcode is aligned with 4 bytes
> > before calling CalculateSum32 function.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Chen A Chen
> > Cc: Ray Ni
> > Cc: Eric Dong
> > ---
> > UefiCpuPkg/Library/MpInitLib/Microcode.c | 31
> --
> > -
> > 1 file changed, 20 insertions(+), 11 deletions(-)
> >
> > diff --git a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> > b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> > index 5f9ae22794..643a6f94f4 100644
> > --- a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> > +++ b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> > @@ -166,20 +166,29 @@ MicrocodeDetect (
> > //
> > CorrectMicrocode = FALSE;
> >
> > -//
> > -// Save an in-complete CheckSum32 from CheckSum Part1 for common
> > parts.
> > -//
> > if (MicrocodeEntryPoint->DataSize == 0) {
> > - InCompleteCheckSum32 = CalculateSum32 (
> > - (UINT32 *) MicrocodeEntryPoint,
> > - sizeof (CPU_MICROCODE_HEADER) + 2000
> > - );
> > + TotalSize = sizeof (CPU_MICROCODE_HEADER) + 2000;
> > } else {
> > - InCompleteCheckSum32 = CalculateSum32 (
> > - (UINT32 *) MicrocodeEntryPoint,
> > - sizeof (CPU_MICROCODE_HEADER) +
> MicrocodeEntryPoint-
> > >DataSize
> > - );
> > + TotalSize = sizeof (CPU_MICROCODE_HEADER) +
> > + MicrocodeEntryPoint-
> > >DataSize;
> > }
> > +
> > +///
> > +/// Check overflow and whether TotalSize is aligned with 4 bytes.
> > +///
> > +if ( ((UINTN)MicrocodeEntryPoint + TotalSize) > MicrocodeEnd ||
> > + (TotalSize & 0x3) != 0
> > + ) {
> > + MicrocodeEntryPoint = (CPU_MICROCODE_HEADER *) (((UINTN)
> > MicrocodeEntryPoint) + SIZE_1KB);
> > + continue;
> > +}
> > +
> > +//
> > +// Save an in-complete CheckSum32 from CheckSum Part1 for common
> > parts.
> > +//
> > +InCompleteCheckSum32 = CalculateSum32 (
> > + (UINT32 *) MicrocodeEntryPoint,
> > + TotalSize
> > + );
> > InCompleteCheckSum32 -= MicrocodeEntryPoint-
> > >ProcessorSignature.Uint32;
> > InCompleteCheckSum32 -= MicrocodeEntryPoint->ProcessorFlags;
> > InCompleteCheckSum32 -= MicrocodeEntryPoint->Checksum;
> > --
> > 2.16.2.windows.1
> >
> > ___
> > 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
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] EmulatorPkg/Sec: Don't install TemporaryRamSupport PPI
> -Original Message- > From: edk2-devel On Behalf Of Jordan > Justen > Sent: Wednesday, March 6, 2019 5:48 AM > To: Ni, Ray ; edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Laszlo Ersek > > Subject: Re: [edk2] [PATCH] EmulatorPkg/Sec: Don't install > TemporaryRamSupport PPI > > On 2019-03-04 18:37:03, Ni, Ray wrote: > > > > > -Original Message- > > > From: edk2-devel On Behalf Of > > > Jordan Justen > > > Sent: Sunday, March 3, 2019 5:45 AM > > > To: Ni, Ray ; edk2-devel@lists.01.org > > > Subject: Re: [edk2] [PATCH] EmulatorPkg/Sec: Don't install > > > TemporaryRamSupport PPI > > > > > > On 2019-03-02 04:11:11, Ray Ni wrote: > > > > > > > > So this patch removes TemporaryRamSupport PPI implementation from > > > > EmulatorPkg/Sec module to fix the boot failure when using GCC5. > > > > > > I don't think we should just hide the known bug with the > > > TemporaryRamSupport PPI implementation in the PEI Core. > > > > > > I would agree that we should make this change after addressing that. > > > > Jordan, > > I have a goal to replace Nt32 with EmulatorPkg before Q2 stable tag release. > > I understand we need more discussions on how to fix the PeiCore bug. > > So I don't want this blocks the Nt32 deletion. > > Given the choice of fixing a known bug in PEI Core relating to the PI spec > TemporaryRamSupport PPI, or deleting Nt32, I would choose fixing the bug. > > But, why not fix the bug, and then make this change? > Mike, Liming, Jian, Can you please review Jordan's patch to fix the code calling TemporaryRamSupport PPI in PeiCore with some assembly code? Personally I don't like the assembly code. But you are the experts and maintainers, I am ok if you give a R-b. Ard, Leif, Jordan is fixing a bug in PeiCore but only fixing x86. I am not sure whether ARM code also contains such TemporaryRamSupport PPI issue. Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] UefiCpuPkg/Microcode.c: Add verification before calculate CheckSum32
Reviewed-by: Ray Ni
> -Original Message-
> From: edk2-devel On Behalf Of Chen A
> Chen
> Sent: Tuesday, March 5, 2019 8:21 AM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric
> Subject: [edk2] [PATCH] UefiCpuPkg/Microcode.c: Add verification before
> calculate CheckSum32
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1020
>
> Should make sure the TotalSize of Microcode is aligned with 4 bytes
> before calling CalculateSum32 function.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> Cc: Ray Ni
> Cc: Eric Dong
> ---
> UefiCpuPkg/Library/MpInitLib/Microcode.c | 31 --
> -
> 1 file changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> index 5f9ae22794..643a6f94f4 100644
> --- a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> +++ b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> @@ -166,20 +166,29 @@ MicrocodeDetect (
> //
> CorrectMicrocode = FALSE;
>
> -//
> -// Save an in-complete CheckSum32 from CheckSum Part1 for common
> parts.
> -//
> if (MicrocodeEntryPoint->DataSize == 0) {
> - InCompleteCheckSum32 = CalculateSum32 (
> - (UINT32 *) MicrocodeEntryPoint,
> - sizeof (CPU_MICROCODE_HEADER) + 2000
> - );
> + TotalSize = sizeof (CPU_MICROCODE_HEADER) + 2000;
> } else {
> - InCompleteCheckSum32 = CalculateSum32 (
> - (UINT32 *) MicrocodeEntryPoint,
> - sizeof (CPU_MICROCODE_HEADER) +
> MicrocodeEntryPoint-
> >DataSize
> - );
> + TotalSize = sizeof (CPU_MICROCODE_HEADER) + MicrocodeEntryPoint-
> >DataSize;
> }
> +
> +///
> +/// Check overflow and whether TotalSize is aligned with 4 bytes.
> +///
> +if ( ((UINTN)MicrocodeEntryPoint + TotalSize) > MicrocodeEnd ||
> + (TotalSize & 0x3) != 0
> + ) {
> + MicrocodeEntryPoint = (CPU_MICROCODE_HEADER *) (((UINTN)
> MicrocodeEntryPoint) + SIZE_1KB);
> + continue;
> +}
> +
> +//
> +// Save an in-complete CheckSum32 from CheckSum Part1 for common
> parts.
> +//
> +InCompleteCheckSum32 = CalculateSum32 (
> + (UINT32 *) MicrocodeEntryPoint,
> + TotalSize
> + );
> InCompleteCheckSum32 -= MicrocodeEntryPoint-
> >ProcessorSignature.Uint32;
> InCompleteCheckSum32 -= MicrocodeEntryPoint->ProcessorFlags;
> InCompleteCheckSum32 -= MicrocodeEntryPoint->Checksum;
> --
> 2.16.2.windows.1
>
> ___
> 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
Re: [edk2] [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for Wake up Buffer.
Eric,
I agree with the code change. It fixes the memtest86 problem through
a very simple code change.
But I think we do need a very meaningful comments to describe a such simple
code change.
Comments below:
1. Please make sure each line of commit message doesn't exceed 70.
> -Original Message-
> From: Dong, Eric
> Sent: Tuesday, March 5, 2019 10:07 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray
> Subject: [Patch] UefiCpuPkg/MpInitLib: Direct allocate buffer for Wake up
> Buffer.
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=1538
>
> Current CpuDxe driver "borrows" Wakeup Buffer (through Allocate & free
> to get the buffer pointer, backup the buffer data before using it and
> restore it after using). Now this logic met a problem described in
> the above BZ because the test tool and the CpuDxe both use the same
> memory at the same time.
2. Can you describe the issue more clearly in the commit message?
What problem is met? What's the tool?
>
> In order to fix the above issue, CpuDxe changed to allocate the buffer
> below 1M instead of borrow it. After investigation, we found below
> 0x88000 is the possible space which can be used.
3. What investigation was made to choose 0x88000?
> For now, range
> 0x6 ~ 0x88000 used for Legacy OPROMs by LegacyBios driver. And it
> tries to allocate these range page(4K size) by page. It just reports
> warning message if specific page been used by others already.
>
> Also CpuDxe driver will produce CPU arch protocol and LegacyBios driver
> has dependency for this protocol. So CpuDxe driver will start before
> LegacyBios driver and CpuDxe driver can allocate that space successful.
>
> With this change, CpuDxe driver will use 0x87000 ~ 0x88000 as wakeup
> buffer.
4. What if someone allocates the exact page? Will CpuDxe driver fail to start?
>
> Cc: Ray Ni
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong
> ---
> UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 30 +++
> ---
> 1 file changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> index b2307cbb61..5bc9a47efb 100644
> --- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
> @@ -76,7 +76,7 @@ SaveCpuMpData (
> }
>
> /**
> - Get available system memory below 1MB by specified size.
> + Get available system memory below 0x88000 by specified size.
>
>@param[in] WakeupBufferSize Wakeup buffer size required
>
> @@ -91,7 +91,19 @@ GetWakeupBuffer (
>EFI_STATUS Status;
>EFI_PHYSICAL_ADDRESSStartAddress;
>
> - StartAddress = BASE_1MB;
> + //
> + // Current "Borrow" space mechanism caused potential race condition if
> both
> + // AP and the original owner use the share space.
> + //
5. future code reader cannot understand what "current borrow mechanism" because
you change the implementation.
> + // LegacyBios driver tries to allocate 4K pages between 0x6 ~ 0x88000
> + // space. It will just report an waring message if the page has been
> allocate
> + // by other drivers.
6. The above wording describes the behavior of LegacyBios driver. What's the
relation ship between the LegacyBios driver behavior and the new implementation?
> + // LagacyBios driver depends on CPU Arch protocol, so it will start after
> + // CpuDxe driver which produce Cpu Arch Protocol and use this library.
> + // So below allocate logic will be trigged before LegacyBios driver and it
> + // will always return success.
> + //
> + StartAddress = BASE_512KB + BASE_32KB;
7. If 0x88000 is chosen, why use BASE_512KB + BASE_32KB instead of 0x88000?
Will you remove the hard-code 0x88000 and use BASE_1MB after CSM is EOL?
>Status = gBS->AllocatePages (
>AllocateMaxAddress,
>EfiBootServicesData,
> @@ -99,17 +111,13 @@ GetWakeupBuffer (
>
>);
>ASSERT_EFI_ERROR (Status);
> - if (!EFI_ERROR (Status)) {
> -Status = gBS->FreePages(
> - StartAddress,
> - EFI_SIZE_TO_PAGES (WakeupBufferSize)
> - );
> -ASSERT_EFI_ERROR (Status);
> -DEBUG ((DEBUG_INFO, "WakeupBufferStart = %x, WakeupBufferSize
> = %x\n",
> -(UINTN) StartAddress, WakeupBufferSize));
> - } else {
> + if (EFI_ERROR (Status)) {
> StartAddress = (EFI_PHYSICAL_ADDRESS) -1;
>}
> +
> + DEBUG ((DEBUG_INFO, "WakeupBufferStart = %x, WakeupBufferSize
> = %x\n",
> + (UINTN) StartAddress, WakeupBufferSize));
> +
>return (UINTN) StartAddress;
> }
>
> --
> 2.15.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] EmulatorPkg/Sec: Don't install TemporaryRamSupport PPI
> -Original Message- > From: edk2-devel On Behalf Of Jordan > Justen > Sent: Sunday, March 3, 2019 5:45 AM > To: Ni, Ray ; edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH] EmulatorPkg/Sec: Don't install > TemporaryRamSupport PPI > > On 2019-03-02 04:11:11, Ray Ni wrote: > > > > So this patch removes TemporaryRamSupport PPI implementation from > > EmulatorPkg/Sec module to fix the boot failure when using GCC5. > > I don't think we should just hide the known bug with the > TemporaryRamSupport PPI implementation in the PEI Core. > > I would agree that we should make this change after addressing that. Jordan, I have a goal to replace Nt32 with EmulatorPkg before Q2 stable tag release. I understand we need more discussions on how to fix the PeiCore bug. So I don't want this blocks the Nt32 deletion. And in my opinion, the TemporaryRamSupport PPI that requires being called from assembly code is a design bug. I suggest to change the PI spec instead of changing PeiCore by introducing more assembly code to hide this design bug. Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] UefiCpuPkg/Microcode: Add verification logic before parsing payload
> -Original Message-
> From: edk2-devel On Behalf Of Chen A
> Chen
> Sent: Thursday, February 28, 2019 2:03 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric
> Subject: [edk2] [PATCH 2/2] UefiCpuPkg/Microcode: Add verification logic
> before parsing payload
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1020
>
> The function MicrocodeDetect may receive untrusted input. Add verification
> logic to check Microcode Payload Header.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> Cc: Ray Ni
> Cc: Eric Dong
> ---
> UefiCpuPkg/Library/MpInitLib/Microcode.c | 190
> +--
> 1 file changed, 127 insertions(+), 63 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> index 5f9ae22794..1d5e964791 100644
> --- a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> +++ b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> @@ -32,6 +32,69 @@ GetCurrentMicrocodeSignature (
>return BiosSignIdMsr.Bits.MicrocodeUpdateSignature;
> }
>
> +/**
> + Verify Microcode.
> +
> + @param[in] MicrocodeHeader Point to the Microcode payload buffer.
> +
> + @retval TRUE Valid payload
> + @retval FALSE Invalid payload
> +**/
> +BOOLEAN
> +VerifyMicrocodeHeader (
1. "Verify" cannot tell what the return value stands for. Use
"IsMicrocodeHeaderValid"?
> + IN CPU_MICROCODE_HEADER *MicrocodeHeader
> + )
> +{
> + UINTN TotalSize;
> + UINTN DataSize;
> +
> + if (MicrocodeHeader == NULL) {
> +return FALSE;
> + }
2. Can we use assert here?
> +
> + ///
> + /// Verify Version
> + ///
> + if (MicrocodeHeader->HeaderVersion != 0x1) {
> +return FALSE;
> + }
> + if (MicrocodeHeader->LoaderRevision != 0x1) {
> +return FALSE;
> + }
> +
> + ///
> + /// Verify TotalSize
> + ///
> + if (MicrocodeHeader->DataSize == 0) {
> +TotalSize = 2048;
> + } else {
> +TotalSize = MicrocodeHeader->TotalSize;
> + }
> + if (TotalSize <= sizeof (CPU_MICROCODE_HEADER)) {
> +return FALSE;
> + }
3. Can you please add more comments here to describe the alignment requirement?
> + if ((TotalSize & (SIZE_1KB - 1)) != 0) {
> +return FALSE;
> + }
> +
> + ///
> + /// Verify DataSize
> + ///
> + if (MicrocodeHeader->DataSize == 0) {
> +DataSize = 2048 - sizeof (CPU_MICROCODE_HEADER);
> + } else {
> +DataSize = MicrocodeHeader->DataSize;
> + }
> + if (DataSize > TotalSize - sizeof (CPU_MICROCODE_HEADER)) {
4. if MIcrocodeHeader->DataSize is 0, seems the if-check is redundant.
> +return FALSE;
> + }
5. Can you please add more comments here to describe the alignment requirement?
> + if ((DataSize & 0x3) != 0) {
> +return FALSE;
> + }
> +
> + return TRUE;
> +}
> +
> /**
>Detect whether specified processor can find matching microcode patch and
> load it.
>
> @@ -166,6 +229,18 @@ MicrocodeDetect (
> //
> CorrectMicrocode = FALSE;
>
> +if (!VerifyMicrocodeHeader (MicrocodeEntryPoint)) {
> + //
> + // It is the padding data between the microcode patches for microcode
> patches alignment.
> + // Because the microcode patch is the multiple of 1-KByte, the padding
> data should not
> + // exist if the microcode patch alignment value is not larger than
> 1-KByte.
> So, the microcode
> + // alignment value should be larger than 1-KByte. We could skip
> SIZE_1KB padding data to
> + // find the next possible microcode patch header.
> + //
> + MicrocodeEntryPoint = (CPU_MICROCODE_HEADER *) (((UINTN)
> MicrocodeEntryPoint) + SIZE_1KB);
> + continue;
> +}
> +
> //
> // Save an in-complete CheckSum32 from CheckSum Part1 for common
> parts.
> //
> @@ -184,90 +259,79 @@ MicrocodeDetect (
> InCompleteCheckSum32 -= MicrocodeEntryPoint->ProcessorFlags;
> InCompleteCheckSum32 -= MicrocodeEntryPoint->Checksum;
>
> -if (MicrocodeEntryPoint->HeaderVersion == 0x1) {
> +//
> +// It is the microcode header. It is not the padding data between
> microcode patches
> +// because the padding data should not include 0x0001 and it should
> be the repeated
> +// byte format (like 0xXYXYXYXY).
> +//
> +if (MicrocodeEntryPoint->ProcessorSignature.Uint32 == Eax.Uint32 &&
> +MicrocodeEntryPoint->UpdateRevision > LatestRevision &&
> +(MicrocodeEntryPoint->ProcessorFlags & (1 << PlatformId))
> +) {
>//
> - // It is the microcode header. It is not the padding data between
> microcode patches
> - // because the padding data should not include 0x0001 and it should
> be the repeated
> - // byte format (like 0xXYXYXYXY).
> + // Calculate CheckSum Part1.
>//
> - if (MicrocodeEntryPoint->ProcessorSignature.Uint32 == Eax.Uint32 &&
> - MicrocodeEntryPoint->UpdateRevision > LatestRevision &&
> -
Re: [edk2] [PATCH 1/2] UefiCpuPkg/Microcode: Fix InComplete CheckSum32 issue
Reviewed-by: Ray Ni
> -Original Message-
> From: edk2-devel On Behalf Of Chen A
> Chen
> Sent: Thursday, February 28, 2019 2:03 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric
> Subject: [edk2] [PATCH 1/2] UefiCpuPkg/Microcode: Fix InComplete
> CheckSum32 issue
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1020
>
> The Microcode region indicated by MicrocodePatchAddress PCD may contain
> more than one Microcode entry. We should save InCompleteCheckSum32
> value for each payload. Move the logic for calculate InCompleteCheckSum32
> from the outsize of the do-while loop to the inside.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> Cc: Ray Ni
> Cc: Eric Dong
> ---
> UefiCpuPkg/Library/MpInitLib/Microcode.c | 37 -
> ---
> 1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> index e1f661d6b1..5f9ae22794 100644
> --- a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> +++ b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> @@ -159,30 +159,31 @@ MicrocodeDetect (
>MicrocodeEnd = (UINTN) (CpuMpData->MicrocodePatchAddress +
> CpuMpData->MicrocodePatchRegionSize);
>MicrocodeEntryPoint = (CPU_MICROCODE_HEADER *) (UINTN)
> CpuMpData->MicrocodePatchAddress;
>
> - //
> - // Save an in-complete CheckSum32 from CheckSum Part1 for common
> parts.
> - //
> - if (MicrocodeEntryPoint->DataSize == 0) {
> -InCompleteCheckSum32 = CalculateSum32 (
> - (UINT32 *) MicrocodeEntryPoint,
> - sizeof (CPU_MICROCODE_HEADER) + 2000
> - );
> - } else {
> -InCompleteCheckSum32 = CalculateSum32 (
> - (UINT32 *) MicrocodeEntryPoint,
> - sizeof (CPU_MICROCODE_HEADER) +
> MicrocodeEntryPoint-
> >DataSize
> - );
> - }
> - InCompleteCheckSum32 -= MicrocodeEntryPoint-
> >ProcessorSignature.Uint32;
> - InCompleteCheckSum32 -= MicrocodeEntryPoint->ProcessorFlags;
> - InCompleteCheckSum32 -= MicrocodeEntryPoint->Checksum;
> -
>do {
> //
> // Check if the microcode is for the Cpu and the version is newer
> // and the update can be processed on the platform
> //
> CorrectMicrocode = FALSE;
> +
> +//
> +// Save an in-complete CheckSum32 from CheckSum Part1 for common
> parts.
> +//
> +if (MicrocodeEntryPoint->DataSize == 0) {
> + InCompleteCheckSum32 = CalculateSum32 (
> + (UINT32 *) MicrocodeEntryPoint,
> + sizeof (CPU_MICROCODE_HEADER) + 2000
> + );
> +} else {
> + InCompleteCheckSum32 = CalculateSum32 (
> + (UINT32 *) MicrocodeEntryPoint,
> + sizeof (CPU_MICROCODE_HEADER) +
> MicrocodeEntryPoint-
> >DataSize
> + );
> +}
> +InCompleteCheckSum32 -= MicrocodeEntryPoint-
> >ProcessorSignature.Uint32;
> +InCompleteCheckSum32 -= MicrocodeEntryPoint->ProcessorFlags;
> +InCompleteCheckSum32 -= MicrocodeEntryPoint->Checksum;
> +
> if (MicrocodeEntryPoint->HeaderVersion == 0x1) {
>//
>// It is the microcode header. It is not the padding data between
> microcode patches
> --
> 2.16.2.windows.1
>
> ___
> 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
Re: [edk2] [PATCH v3 2/2] MdeModulePkg/RamDiskDxe: Restrict on RAM disk size (CVE-2018-12180)
Reviewed-by: Ray Ni
> -Original Message-
> From: Wu, Hao A
> Sent: Tuesday, February 26, 2019 8:57 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Wang, Jian J ;
> Ni, Ray ; Zeng, Star ; Laszlo Ersek
>
> Subject: [PATCH v3 2/2] MdeModulePkg/RamDiskDxe: Restrict on RAM disk
> size (CVE-2018-12180)
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1134
>
> Originally, the block size of created Ram disks is hard-coded to 512 bytes.
> However, if the total size of the Ram disk is not a multiple of 512 bytes,
> there
> will be potential memory access issues when dealing with the last block of
> the Ram disk.
>
> This commit will adjust the block size of the Ram disks to ensure that the
> total
> size is a multiple of the block size.
>
> Cc: Jian J Wang
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h | 6 +++---
> MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c | 20
> ++--
> MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c | 5 +++--
> 3 files changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h
> b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h
> index 08a8ca94c9..72f2bfe179 100644
> --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h
> +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskImpl.h
> @@ -1,7 +1,7 @@
> /** @file
>The header file of RamDiskDxe driver.
>
> - Copyright (c) 2016, Intel Corporation. All rights reserved.
> + Copyright (c) 2016 - 2019, Intel Corporation. All rights
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found at @@ -49,9 +49,9 @@ ///
>
> //
> -// Block size for RAM disk
> +// Default block size for RAM disk
> //
> -#define RAM_DISK_BLOCK_SIZE 512
> +#define RAM_DISK_DEFAULT_BLOCK_SIZE 512
>
> //
> // Iterate through the double linked list. NOT delete safe diff --git
> a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
> b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
> index 4f74b5ef15..8926ad7d2f 100644
> --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
> +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskBlockIo.c
> @@ -1,7 +1,7 @@
> /** @file
>Produce EFI_BLOCK_IO_PROTOCOL on a RAM disk device.
>
> - Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2016 - 2019, Intel Corporation. All rights
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found at @@ -54,6 +54,7 @@ RamDiskInitBlockIo (
>EFI_BLOCK_IO_PROTOCOL *BlockIo;
>EFI_BLOCK_IO2_PROTOCOL *BlockIo2;
>EFI_BLOCK_IO_MEDIA *Media;
> + UINT32 Remainder;
>
>BlockIo = >BlockIo;
>BlockIo2 = >BlockIo2;
> @@ -69,11 +70,18 @@ RamDiskInitBlockIo (
>Media->LogicalPartition = FALSE;
>Media->ReadOnly = FALSE;
>Media->WriteCaching = FALSE;
> - Media->BlockSize= RAM_DISK_BLOCK_SIZE;
> - Media->LastBlock= DivU64x32 (
> - PrivateData->Size + RAM_DISK_BLOCK_SIZE - 1,
> - RAM_DISK_BLOCK_SIZE
> - ) - 1;
> +
> + for (Media->BlockSize = RAM_DISK_DEFAULT_BLOCK_SIZE;
> + Media->BlockSize >= 1;
> + Media->BlockSize = Media->BlockSize >> 1) {
> +Media->LastBlock = DivU64x32Remainder (PrivateData->Size, Media-
> >BlockSize, ) - 1;
> +if (Remainder == 0) {
> + break;
> +}
> + }
> + ASSERT (Media->BlockSize != 0);
> +
> + return;
> }
>
>
> diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c
> b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c
> index 6784e2b2f1..e8250d5c1b 100644
> --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c
> +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskProtocol.c
> @@ -1,7 +1,7 @@
> /** @file
>The realization of EFI_RAM_DISK_PROTOCOL.
>
> - Copyright (c) 2016, Intel Corporation. All rights reserved.
> + Copyright (c) 2016 - 2019, Intel Corporation. All rights
> + reserved.
>(C)
Re: [edk2] [PATCH v3 1/2] MdeModulePkg/PartitionDxe: Ensure blocksize holds MBR (CVE-2018-12180)
Reviewed-by: Ray Ni
> -Original Message-
> From: Wu, Hao A
> Sent: Tuesday, February 26, 2019 8:57 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Wang, Jian J ;
> Ni, Ray ; Zeng, Star ; Laszlo Ersek
>
> Subject: [PATCH v3 1/2] MdeModulePkg/PartitionDxe: Ensure blocksize
> holds MBR (CVE-2018-12180)
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1134
>
> The commit adds checks for detecting GPT and MBR partitions.
>
> These checks will ensure that the device block size is big enough to hold
> an MBR (512 bytes).
>
> Cc: Jian J Wang
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c | 9 -
> MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c | 9 -
> 2 files changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c
> b/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c
> index fe87761bde..d679cc208b 100644
> --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c
> +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c
> @@ -14,7 +14,7 @@
>partition content and validate the GPT table and GPT entry.
>
> Copyright (c) 2018 Qualcomm Datacenter Technologies, Inc.
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> which accompanies this distribution. The full text of the license may be
> found at
> @@ -237,6 +237,13 @@ PartitionInstallGptChildHandles (
>GptValidStatus = EFI_NOT_FOUND;
>
>//
> + // Ensure the block size can hold the MBR
> + //
> + if (BlockSize < sizeof (MASTER_BOOT_RECORD)) {
> +return EFI_NOT_FOUND;
> + }
> +
> + //
>// Allocate a buffer for the Protective MBR
>//
>ProtectiveMbr = AllocatePool (BlockSize);
> diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
> b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
> index b1a99ee85b..419f8a17a7 100644
> --- a/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
> +++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Mbr.c
> @@ -13,7 +13,7 @@
>
> Copyright (c) 2018 Qualcomm Datacenter Technologies, Inc.
> Copyright (c) 2014, Hewlett-Packard Development Company, L.P.
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials
> are licensed and made available under the terms and conditions of the BSD
> License
> which accompanies this distribution. The full text of the license may be
> found at
> @@ -150,6 +150,13 @@ PartitionInstallMbrChildHandles (
>MediaId = BlockIo->Media->MediaId;
>LastBlock = BlockIo->Media->LastBlock;
>
> + //
> + // Ensure the block size can hold the MBR
> + //
> + if (BlockSize < sizeof (MASTER_BOOT_RECORD)) {
> +return EFI_NOT_FOUND;
> + }
> +
>Mbr = AllocatePool (BlockSize);
>if (Mbr == NULL) {
> return Found;
> --
> 2.12.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 1/5] MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep.
On 2/23/2019 1:16 AM, Laszlo Ersek wrote: Yes, I was fully aware of that. However: The issue is that, in the BmReportLoadFailure() function, we do some work*before* we call REPORT_STATUS_CODE_EX(). We have an ASSERT(), a ZeroMem(), and a field assignment. If status code reporting is disabled for EFI_ERROR_CODE in the platform, then said work will be wasted. We can optimize this by checking for ReportErrorCodeEnabled() up-front, because we know for sure that later on we will report the status code with EFI_ERROR_CODE type. In other words, this approach is similar to DEBUG_CODE(). In some cases, logging a piece of information with DEBUG() takes non-trivial computation. And it would be a waste, for example in RELEASE builds, to perform the computation, and then throw away only the result (the log message). Therefore the DEBUG_CODE macro is used, and the whole work is eliminated in RELEASE builds. The idea is the same here. If the compiler can statically deduce that ReportErrorCodeEnabled() will always return FALSE -- for example because the ReportStatusCodeLib instance in question looks at "PcdReportStatusCodePropertyMask", and the PCD is Fixed-at-Build, and the corresponding bit is clear --, then the compiler can eliminate the entire BmReportLoadFailure() function. This is good for both flash usage and for performance. I'm fine either way, but first, please confirm again that you really want me to remove the ReportErrorCodeEnabled() check, before pushing. Thanks! Laszlo Thanks for the explanation. I am fine with both. Reviewed-by: Ray Ni -- Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1] MdeModulePkg/UfsBlockIoPei: Correct use of 'DeviceIndex' in BlkIO PPI
Reviewed-by: Ray Ni
> -Original Message-
> From: edk2-devel On Behalf Of Hao Wu
> Sent: Friday, February 15, 2019 10:55 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A
> Subject: [edk2] [PATCH v1] MdeModulePkg/UfsBlockIoPei: Correct use of
> 'DeviceIndex' in BlkIO PPI
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1474
>
> Within UfsBlockIoPei, the current implementation of the Block IO(2)
> services:
>
> UfsBlockIoPeimGetMediaInfo
> UfsBlockIoPeimReadBlocks
> UfsBlockIoPeimGetMediaInfo2
> UfsBlockIoPeimReadBlocks2
>
> does not handle the input parameter 'DeviceIndex' properly.
>
> According to both of the PI spec and the function description comments:
>
> > DeviceIndexSpecifies the block device to which the function wants
> >to talk. ... This index is a number from one to
> >NumberBlockDevices.
>
> But current codes incorrectly treat the valid range of 'DeviceIndex' as 0 to
> (NumberBlockDevices - 1).
>
> This commit is to address this issue.
>
> Cc: Jian J Wang
> Cc: Ray Ni
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c | 56 +++-
>
> 1 file changed, 31 insertions(+), 25 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c
> b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c
> index 204e456413..c969ab45f5 100644
> --- a/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c
> +++ b/MdeModulePkg/Bus/Ufs/UfsBlockIoPei/UfsBlockIoPei.c
> @@ -1,6 +1,6 @@
> /** @file
>
> - Copyright (c) 2014 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2014 - 2019, Intel Corporation. All rights
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found at @@ -587,15 +587,17 @@ UfsBlockIoPeimGetMediaInfo (
>EFI_SCSI_DISK_CAPACITY_DATA16 Capacity16;
>UINTN DataLength;
>BOOLEANNeedRetry;
> + UINTN Lun;
>
>Private = GET_UFS_PEIM_HC_PRIVATE_DATA_FROM_THIS (This);
>NeedRetry = TRUE;
>
> - if (DeviceIndex >= UFS_PEIM_MAX_LUNS) {
> + if ((DeviceIndex == 0) || (DeviceIndex > UFS_PEIM_MAX_LUNS)) {
> return EFI_INVALID_PARAMETER;
>}
>
> - if ((Private->Luns.BitMask & (BIT0 << DeviceIndex)) == 0) {
> + Lun = DeviceIndex - 1;
> + if ((Private->Luns.BitMask & (BIT0 << Lun)) == 0) {
> return EFI_ACCESS_DENIED;
>}
>
> @@ -609,7 +611,7 @@ UfsBlockIoPeimGetMediaInfo (
>do {
> Status = UfsPeimTestUnitReady (
> Private,
> - DeviceIndex,
> + Lun,
> ,
>
> );
> @@ -621,7 +623,7 @@ UfsBlockIoPeimGetMediaInfo (
>continue;
> }
>
> -Status = UfsPeimParsingSenseKeys (&(Private->Media[DeviceIndex]),
> , );
> +Status = UfsPeimParsingSenseKeys (&(Private->Media[Lun]),
> + , );
> if (EFI_ERROR (Status)) {
>return EFI_DEVICE_ERROR;
> }
> @@ -630,7 +632,7 @@ UfsBlockIoPeimGetMediaInfo (
>
>DataLength = sizeof (EFI_SCSI_DISK_CAPACITY_DATA);
>SenseDataLength = 0;
> - Status = UfsPeimReadCapacity (Private, DeviceIndex, , (UINT32
> *), NULL, );
> + Status = UfsPeimReadCapacity (Private, Lun, , (UINT32
> + *), NULL, );
>if (EFI_ERROR (Status)) {
> return EFI_DEVICE_ERROR;
>}
> @@ -639,22 +641,22 @@ UfsBlockIoPeimGetMediaInfo (
>(Capacity.LastLba1 == 0xff) && (Capacity.LastLba0 == 0xff)) {
> DataLength = sizeof (EFI_SCSI_DISK_CAPACITY_DATA16);
> SenseDataLength = 0;
> -Status = UfsPeimReadCapacity16 (Private, DeviceIndex, ,
> (UINT32 *), NULL, );
> +Status = UfsPeimReadCapacity16 (Private, Lun, , (UINT32
> + *), NULL, );
> if (EFI_ERROR (Status)) {
>return EFI_DEVICE_ERROR;
> }
> -Private->Media[DeviceIndex].LastBlock = ((UINT32)Capacity16.LastLba3
> << 24) | (Capacity16.LastLba2 << 16) | (Capacity16.LastLba1 << 8) |
> Capacity16.LastLba0;
> -Private->Media[DeviceIndex].LastBlock |= LShiftU64
> ((UINT64)Capacity16.LastLba7, 56) | LShiftU64((UINT64)Capacity16.LastLba6,
> 48) | LShiftU64 ((UINT64)Capacity16.LastLba5, 40) | LShiftU64
> ((UINT64)Capacity16.LastLba4, 32);
> -Private->Media[DeviceIndex].BlockSize = (Capacity16.BlockSize3 << 24) |
> (Capacity16.BlockSize2 << 16) | (Capacity16.BlockSize1 << 8) |
> Capacity16.BlockSize0;
> +Private->Media[Lun].LastBlock = ((UINT32)Capacity16.LastLba3 << 24) |
> (Capacity16.LastLba2 << 16) | (Capacity16.LastLba1 << 8) |
> Capacity16.LastLba0;
> +Private->Media[Lun].LastBlock |= LShiftU64 ((UINT64)Capacity16.LastLba7,
> 56) | LShiftU64((UINT64)Capacity16.LastLba6, 48) | LShiftU64
> ((UINT64)Capacity16.LastLba5, 40) | LShiftU64
Re: [edk2] [PATCH V3 0/4] Add SMM CET support
Reviewed-by: Ray Ni > -Original Message- > From: Yao, Jiewen > Sent: Friday, February 22, 2019 9:31 PM > To: edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Gao, Liming > ; Dong, Eric ; Ni, Ray > ; Laszlo Ersek ; Yao, Jiewen > > Subject: [PATCH V3 0/4] Add SMM CET support > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1521 > > V3: > Add Nasm.inc to include CET related instruction as MACRO. > This is the only place to use DB. > Any other NASM just use the MACRO - > SETSSBSY, READSSP_[E|R]AX, INCSSP_[E|R]AX = > > V2: > Fix emulation platform issue. > The NT32 platform cannot access CR4 register. > So we add a global PCD to choose disable CR4 access in SetJump/LongJump. > gEfiMdePkgTokenSpaceGuid.PcdControlFlowEnforcementPropertyMask > = > > This patch series implement add CET ShadowStack support for SMM. > > The CET document can be found at: > https://software.intel.com/sites/default/files/managed/4d/2a/control-flow- > enforcement-technology-preview.pdf > > Patch 1 adds SSP (ShadowStackPointer) to JUMP_BUFFER. > Patch 2 adds Control Protection exception (CP#) dump info. > Patch 3 adds CET ShadowStack support in SMM. > > For more detail please refer to each patch. > > I also post all update to https://github.com/jyao1/edk2/tree/CET_V2 > > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Eric Dong > Cc: Ray Ni > Cc: Laszlo Ersek > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Yao Jiewen > > Jiewen Yao (4): > MdePkg/Include: Add Nasm.inc > MdePkg/BaseLib: Add Shadow Stack Support for X86. > UefiCpuPkg/ExceptionLib: Add CET support. > UefiCpuPkg/PiSmmCpu: Add Shadow Stack Support for X86 SMM. > > MdePkg/Include/Ia32/Nasm.inc | 28 > MdePkg/Include/Library/BaseLib.h | 2 + > MdePkg/Include/X64/Nasm.inc | 28 > MdePkg/Library/BaseLib/BaseLib.inf| 3 +- > MdePkg/Library/BaseLib/Ia32/LongJump.c| 28 +++- > MdePkg/Library/BaseLib/Ia32/LongJump.nasm | 25 +++- > MdePkg/Library/BaseLib/Ia32/SetJump.c | 28 +++- > MdePkg/Library/BaseLib/Ia32/SetJump.nasm | 23 +++- > MdePkg/Library/BaseLib/X64/LongJump.nasm | 27 +++- > MdePkg/Library/BaseLib/X64/SetJump.nasm | 23 +++- > MdePkg/MdePkg.dec | 7 + > .../Include/Library/SmmCpuFeaturesLib.h | 23 +++- > .../CpuExceptionCommon.c | 7 +- > .../CpuExceptionCommon.h | 3 +- > .../Ia32/ArchExceptionHandler.c | 5 +- > .../X64/ArchExceptionHandler.c| 5 +- > UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Cet.nasm | 39 ++ > UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 38 +- > UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmiEntry.nasm | 99 ++- > .../PiSmmCpuDxeSmm/Ia32/SmiException.nasm | 6 +- > UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/SmmFuncsArch.c | 57 - > UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 12 +- > UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c| 97 -- > UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h| 103 > ++- > UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf | 6 +- > .../PiSmmCpuDxeSmm/SmmCpuMemoryManagement.c | 85 - > UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.c| 18 ++- > UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfile.h| 4 +- > UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c| 4 +- > UefiCpuPkg/PiSmmCpuDxeSmm/X64/Cet.nasm| 40 ++ > UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 39 +- > UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmiEntry.nasm | 120 > +- > UefiCpuPkg/PiSmmCpuDxeSmm/X64/SmmFuncsArch.c | 58 - > UefiCpuPkg/UefiCpuPkg.dec | 6 +- > 34 files changed, 1034 insertions(+), 62 deletions(-) create mode 100644 > MdePkg/Include/Ia32/Nasm.inc create mode 100644 > MdePkg/Include/X64/Nasm.inc create mode 100644 > UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/Cet.nasm > create mode 100644 UefiCpuPkg/PiSmmCpuDxeSmm/X64/Cet.nasm > > -- > 2.19.2.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH V2 2/3] UefiCpuPkg/ExceptionLib: Add CET support.
Reviewed-by: Ray Ni
> -Original Message-
> From: Yao, Jiewen
> Sent: Friday, February 22, 2019 7:00 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric ; Ni, Ray ; Laszlo Ersek
> ; Yao, Jiewen
> Subject: [PATCH V2 2/3] UefiCpuPkg/ExceptionLib: Add CET support.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1521
>
> Add information dump for Control Protection exception.
>
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yao Jiewen
> ---
> UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c| 7
> ---
> UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h| 3
> ++-
> UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c | 5
> +++--
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c | 5
> +++--
> 4 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
> index 0576144a97..ca210d1de2 100644
> --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
> +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.c
> @@ -1,7 +1,7 @@
> /** @file
>CPU Exception Handler Library common functions.
>
> - Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2012 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found
> at
> @@ -20,7 +20,7 @@
> //
> // 1 means an error code will be pushed, otherwise 0
> //
> -CONST UINT32 mErrorCodeFlag = 0x00027d00;
> +CONST UINT32 mErrorCodeFlag = 0x00227d00;
>
> //
> // Define the maximum message length
> @@ -49,7 +49,8 @@ CONST CHAR8 *mExceptionNameStr[] = {
>"#AC - Alignment Check",
>"#MC - Machine-Check",
>"#XM - SIMD floating-point",
> - "#VE - Virtualization"
> + "#VE - Virtualization",
> + "#CP - Control Protection"
> };
>
> #define EXCEPTION_KNOWN_NAME_NUM (sizeof (mExceptionNameStr) /
> sizeof (CHAR8 *))
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> index 83e55ab828..edf46cb60d 100644
> --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/CpuExceptionCommon.h
> @@ -1,7 +1,7 @@
> /** @file
>Common header file for CPU Exception Handler Library.
>
> - Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2012 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found
> at
> @@ -39,6 +39,7 @@
> #define IA32_PF_EC_RSVD BIT3
> #define IA32_PF_EC_ID BIT4
> #define IA32_PF_EC_PK BIT5
> +#define IA32_PF_EC_SS BIT6
> #define IA32_PF_EC_SGX BIT15
>
> #include "ArchInterruptDefs.h"
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
> index 531258610a..f3d993af75 100644
> --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
> @@ -1,7 +1,7 @@
> /** @file
>IA32 CPU Exception Handler functons.
>
> - Copyright (c) 2012 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2012 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found
> at
> @@ -326,13 +326,14 @@ DumpCpuContext (
>);
> if (ExceptionType == EXCEPT_IA32_PAGE_FAULT) {
>InternalPrintMessage (
> -" I:%x R:%x U:%x W:%x P:%x PK:%x S:%x",
> +" I:%x R:%x U:%x W:%x P:%x PK:%x SS:%x SGX:%x",
> (SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_ID) !=
> 0,
> (SystemContext.Syste
Re: [edk2] [PATCH V2 1/3] MdePkg/BaseLib: Add Shadow Stack Support for X86.
Reviewed-by: Ray Ni
> -Original Message-
> From: Yao, Jiewen
> Sent: Friday, February 22, 2019 7:00 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric ; Ni, Ray ; Laszlo Ersek
> ; Yao, Jiewen
> Subject: [PATCH V2 1/3] MdePkg/BaseLib: Add Shadow Stack Support for X86.
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1521
>
> This patch adds SSP - shadow stack pointer to JumpBuffer.
> It will be used for the platform that enabled CET/ShadowStack.
>
> We add gEfiMdePkgTokenSpaceGuid.PcdControlFlowEnforcementPropertyMask
> to control the global enable/disable.
>
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yao Jiewen
> ---
> MdePkg/Include/Library/BaseLib.h | 2 ++
> MdePkg/Library/BaseLib/BaseLib.inf| 3 ++-
> MdePkg/Library/BaseLib/Ia32/LongJump.c| 28 +++-
> MdePkg/Library/BaseLib/Ia32/LongJump.nasm | 23 +++-
> MdePkg/Library/BaseLib/Ia32/SetJump.c | 28 +++-
> MdePkg/Library/BaseLib/Ia32/SetJump.nasm | 21 ++-
> MdePkg/Library/BaseLib/X64/LongJump.nasm | 25 -
> MdePkg/Library/BaseLib/X64/SetJump.nasm | 21 ++-
> MdePkg/MdePkg.dec | 7 +
> 9 files changed, 151 insertions(+), 7 deletions(-)
>
> diff --git a/MdePkg/Include/Library/BaseLib.h
> b/MdePkg/Include/Library/BaseLib.h
> index 9c42f82a7d..616ba2e95b 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -31,6 +31,7 @@ typedef struct {
>UINT32Ebp;
>UINT32Esp;
>UINT32Eip;
> + UINT32Ssp;
> } BASE_LIBRARY_JUMP_BUFFER;
>
> #define BASE_LIBRARY_JUMP_BUFFER_ALIGNMENT 4 @@ -54,6 +55,7 @@
> typedef struct {
>UINT64Rip;
>UINT64MxCsr;
>UINT8 XmmBuffer[160]; ///< XMM6-XMM15.
> + UINT64Ssp;
> } BASE_LIBRARY_JUMP_BUFFER;
>
> #define BASE_LIBRARY_JUMP_BUFFER_ALIGNMENT 8 diff --git
> a/MdePkg/Library/BaseLib/BaseLib.inf b/MdePkg/Library/BaseLib/BaseLib.inf
> index f25a067a23..a0d6c372f9 100644
> --- a/MdePkg/Library/BaseLib/BaseLib.inf
> +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> @@ -1,7 +1,7 @@
> ## @file
> # Base Library implementation.
> #
> -# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2007 - 2019, Intel Corporation. All rights
> +reserved.
> # Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved. #
> Portions copyright (c) 2011 - 2013, ARM Ltd. All rights reserved. # @@ -
> 620,6 +620,7 @@
>gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength ##
> SOMETIMES_CONSUMES
>gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength ##
> SOMETIMES_CONSUMES
>gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength ##
> SOMETIMES_CONSUMES
> + gEfiMdePkgTokenSpaceGuid.PcdControlFlowEnforcementPropertyMask ##
> SOMETIMES_CONSUMES
>
> [FeaturePcd]
>gEfiMdePkgTokenSpaceGuid.PcdVerifyNodeInList ## CONSUMES diff --git
> a/MdePkg/Library/BaseLib/Ia32/LongJump.c
> b/MdePkg/Library/BaseLib/Ia32/LongJump.c
> index 73973a9cce..2c1feb8373 100644
> --- a/MdePkg/Library/BaseLib/Ia32/LongJump.c
> +++ b/MdePkg/Library/BaseLib/Ia32/LongJump.c
> @@ -1,7 +1,7 @@
> /** @file
>Implementation of _LongJump() on IA-32.
>
> - Copyright (c) 2006 - 2008, Intel Corporation. All rights reserved.
> + Copyright (c) 2006 - 2019, Intel Corporation. All rights
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found
> at @@ -36,6 +36,32 @@ InternalLongJump (
>)
> {
>_asm {
> +mov eax, [PcdGet32 (PcdControlFlowEnforcementPropertyMask)]
> +testeax, eax
> +jz CetDone
> +_emit 0x0F
> +_emit 0x20
> +_emit 0xE0; mov eax, cr4
> +bt eax, 23; check if CET is enabled
> +jnc CetDone
> +
> +mov edx, [esp + 4] ; edx = JumpBuffer
> +mov edx, [edx + 24]; edx = target SSP
> +_emit 0xF3
> +_emit 0x0F
> +_emit 0x1E
> +_emit 0xC8; READSSP EAX
> +sub edx, eax ; edx = delta
> +mov eax, edx ; eax = delta
>
Re: [edk2] [PATCH v3 1/5] MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep.
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, February 21, 2019 6:41 PM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan ; Wu, Hao A ;
> Wang, Jian J ; Ni, Ray ; Sean Brogan
> ; Zeng, Star
> Subject: [PATCH v3 1/5] MdeModulePkg/UefiBootManagerLib: fix
> LoadImage/StartImage status code rep.
> + if (!ReportErrorCodeEnabled ()) {
> +return;
> + }
Sorry I didn't notice this piece of code in V2.
The if-check-return code is not needed here.
Because the implementation of ReportStatusCodeLib is
responsible to do the filter.
See below:
EFI_STATUS
InternalReportStatusCode (
IN EFI_STATUS_CODE_TYPE Type,
IN EFI_STATUS_CODE_VALUEValue,
IN UINT32 Instance,
IN CONST EFI_GUID *CallerId OPTIONAL,
IN EFI_STATUS_CODE_DATA *Data OPTIONAL
)
{
if ((ReportProgressCodeEnabled() && ((Type) & EFI_STATUS_CODE_TYPE_MASK) ==
EFI_PROGRESS_CODE) ||
(ReportErrorCodeEnabled() && ((Type) & EFI_STATUS_CODE_TYPE_MASK) ==
EFI_ERROR_CODE) ||
(ReportDebugCodeEnabled() && ((Type) & EFI_STATUS_CODE_TYPE_MASK) ==
EFI_DEBUG_CODE)) {
...
With the removal of the three lines code, Reviewed-by: Ray Ni
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg: Rename confusion function name
Reviewed-by: Ray Ni
> -Original Message-
> From: Chen, Chen A
> Sent: Friday, February 22, 2019 8:34 AM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A ; Ni, Ray ; Gao,
> Liming
> Subject: [PATCH] MdeModulePkg: Rename confusion function name
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1536
>
> To avoid the confusion caused by function name,
> rename EfiBootManagerGetNextFullDevicePath to
> EfiBootManagerGetNextLoadOptionDevicePath.
> As an API function should add EFIAPI prefix for this function.
>
> Cc: Ray Ni
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c | 2 +-
> MdeModulePkg/Include/Library/UefiBootManagerLib.h | 3 ++-
> MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c| 3 ++-
> 3 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> index f6e46cbdb1..4ff69af1b4 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
> @@ -355,7 +355,7 @@ GetEfiSysPartitionFromBootOptionFilePath (
>//
>do {
> PreFullPath = CurFullPath;
> -CurFullPath = EfiBootManagerGetNextFullDevicePath (DevicePath,
> CurFullPath);
> +CurFullPath = EfiBootManagerGetNextLoadOptionDevicePath (DevicePath,
> CurFullPath);
>
> if (PreFullPath != NULL) {
>FreePool (PreFullPath);
> diff --git a/MdeModulePkg/Include/Library/UefiBootManagerLib.h
> b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
> index 64347ff160..69678a62ca 100644
> --- a/MdeModulePkg/Include/Library/UefiBootManagerLib.h
> +++ b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
> @@ -460,7 +460,8 @@ EfiBootManagerGetBootManagerMenu (
>Caller is responsible to free the memory.
> **/
> EFI_DEVICE_PATH_PROTOCOL *
> -EfiBootManagerGetNextFullDevicePath (
> +EFIAPI
> +EfiBootManagerGetNextLoadOptionDevicePath (
>IN EFI_DEVICE_PATH_PROTOCOL *FilePath,
>IN EFI_DEVICE_PATH_PROTOCOL *FullPath
>);
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> index 9be1633b74..d5957db610 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> @@ -2482,7 +2482,8 @@ EfiBootManagerGetBootManagerMenu (
>Caller is responsible to free the memory.
> **/
> EFI_DEVICE_PATH_PROTOCOL *
> -EfiBootManagerGetNextFullDevicePath (
> +EFIAPI
> +EfiBootManagerGetNextLoadOptionDevicePath (
>IN EFI_DEVICE_PATH_PROTOCOL *FilePath,
>IN EFI_DEVICE_PATH_PROTOCOL *FullPath
>)
> --
> 2.16.2.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] IntelSiliconPkg/MicrocodeUpdate: Fix incorrect checksum issue
Reviewed-by: Ray Ni
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Chen
> A Chen
> Sent: Friday, February 22, 2019 8:49 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH] IntelSiliconPkg/MicrocodeUpdate: Fix incorrect
> checksum issue
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1020
>
> The same issue has fixed in UefiCpuPkg/Microcode.c file.
> Please reference b6f67b4d58b81f12f63f5f8c94cf8af3600297ab
> to get more detail information.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> Cc: Ray Ni
> Cc: Rangasai V Chaganty
> ---
> .../Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c | 10
> +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git
> a/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c
> b/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c
> index 9b5757da71..e45c7a8def 100644
> ---
> a/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c
> +++
> b/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c
> @@ -390,6 +390,7 @@ VerifyMicrocode (
>UINTN DataSize;
>UINT32 CurrentRevision;
>PROCESSOR_INFO *ProcessorInfo;
> + UINT32 InCompleteCheckSum32;
>UINT32 CheckSum32;
>UINTN ExtendedTableLength;
>UINT32 ExtendedTableCount;
> @@ -488,6 +489,10 @@ VerifyMicrocode (
> }
> return EFI_VOLUME_CORRUPTED;
>}
> + InCompleteCheckSum32 = CheckSum32;
> + InCompleteCheckSum32 -= MicrocodeEntryPoint->ProcessorSignature.Uint32;
> + InCompleteCheckSum32 -= MicrocodeEntryPoint->ProcessorFlags;
> + InCompleteCheckSum32 -= MicrocodeEntryPoint->Checksum;
>
>//
>// Check ProcessorSignature/ProcessorFlags
> @@ -522,7 +527,10 @@ VerifyMicrocode (
>} else {
> ExtendedTable = (CPU_MICROCODE_EXTENDED_TABLE
> *)(ExtendedTableHeader + 1);
> for (Index = 0; Index < ExtendedTableCount; Index++) {
> - CheckSum32 = CalculateSum32((UINT32 *)ExtendedTable,
> sizeof(CPU_MICROCODE_EXTENDED_TABLE));
> + CheckSum32 = InCompleteCheckSum32;
> + CheckSum32 += ExtendedTable->ProcessorSignature.Uint32;
> + CheckSum32 += ExtendedTable->ProcessorFlag;
> + CheckSum32 += ExtendedTable->Checksum;
>if (CheckSum32 != 0) {
> DEBUG((DEBUG_ERROR, "VerifyMicrocode - The checksum for
> ExtendedTable entry with index 0x%x is incorrect\n", Index));
>} else {
> --
> 2.16.2.windows.1
>
> ___
> 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
Re: [edk2] [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration
> -Original Message- > From: Justen, Jordan L > Sent: Thursday, February 21, 2019 9:03 AM > To: Gao, Liming ; Ni, Ray ; edk2- > de...@lists.01.org > Cc: Wu, Hao A ; Anthony Perard > ; Laszlo Ersek ; Zeng, > Star ; Andrew Fish > Subject: RE: [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration > > On 2019-02-20 16:15:59, Ni, Ray wrote: > > > -Original Message- > > > From: Justen, Jordan L > > > Sent: Thursday, February 21, 2019 1:44 AM > > > To: Gao, Liming ; Ni, Ray ; > > > edk2- de...@lists.01.org > > > Cc: Wu, Hao A ; Anthony Perard > > > ; Laszlo Ersek ; Zeng, > > > Star > > > Subject: Re: [PATCH 00/10] Fix PEI Core issue during > > > TemporaryRamMigration > > > > > > On 2019-02-20 05:27:21, Ni, Ray wrote: > > > > On 2/19/2019 9:25 PM, Gao, Liming wrote: > > > > > Ray: > > > > > > > > > > Now, real platform has no side effect. So, only TempRamDone > > > > > PPI is produced. For emulator platform, is there any side > > > > > effect when both Temporary RAM and Permanent RAM are > enabled? > > > > > > > > > > > > > No side effect when both of T-RAM and P-RAM are enabled. > > > > Which means no side effect when neither of the PPIs is produced. > > > > But for demo purpose, I think producing TemporaryRamDone PPI > makes > > > sense. > > > > > > In addition to being a demo/sample, it also provides a check that no > > > modules are accessing temp-ram after temp-ram should no longer be > used. > > > > > > > I will work out patches for EmulatorPkg to produce TemoraryRamDone. > > > > > > I think we should first fix TemporaryRamSupport usage. Otherwise, we > > > are just hiding the bug. > > > > > > Have you tried these patches to verify that they fix the issue in your > setup? > > > Have you taken a look at the patches to see what problem is being fixed? > > > > I feel the change to PeiCore is a bit complex and introduce additional deps > (assembly). > > I asked about this last November, and as I recall, Andrew said we can (and > should) add assembly to PEI Core if it is required to meet the specs. > > > Behavior of ARM and x86 becomes different. (The patch only fixes x86 > > issue.) > > Yes. Similar code should be written for ARM, but I don't have experience > with ARM assembly code. > > > Given there is no real requirement on this, > > Isn't the requirement to be compatible with the PI specification? > > It seems that at least you and Liu Yu have encountered a build environment > that produces code for PEI Core that isn't compatible with the PI > specification. > > It doesn't seem like the best response to this is to just change the platform > boot path and ignore the bug. The environment Liu Yu and I encountered is the same Emulator environment. I think the code change you did to PeiCore is great. It re-wrote the C code in assembly to make sure the implementation doesn't rely on C compiler's behavior. But looking back, if a PI spec interface should depend on assembly Implementation, I will pursue to change the PI spec interface directly. Given the fact that no platform is producing this RamMigration PPI, changing PI spec then changing the PeiCore to use new PPI interface has no impact. To be honest, I don't want to introduce complexity to PeiCore or edk2. That's my only concern. > > I do agree that after this issue is fixed, we can then consider changing the > platform. The downside to changing it then will be to leave an untested code > path, but at least we won't leave it with a known bug present. > > -Jordan > > > I prefer to not change PeiCore. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration
> -Original Message- > From: Justen, Jordan L > Sent: Thursday, February 21, 2019 1:44 AM > To: Gao, Liming ; Ni, Ray ; edk2- > de...@lists.01.org > Cc: Wu, Hao A ; Anthony Perard > ; Laszlo Ersek ; Zeng, > Star > Subject: Re: [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration > > On 2019-02-20 05:27:21, Ni, Ray wrote: > > On 2/19/2019 9:25 PM, Gao, Liming wrote: > > > Ray: > > > > > > Now, real platform has no side effect. So, only TempRamDone > > > PPI is produced. For emulator platform, is there any side > > > effect when both Temporary RAM and Permanent RAM are enabled? > > > > > > > No side effect when both of T-RAM and P-RAM are enabled. > > Which means no side effect when neither of the PPIs is produced. > > But for demo purpose, I think producing TemporaryRamDone PPI makes > sense. > > In addition to being a demo/sample, it also provides a check that no modules > are accessing temp-ram after temp-ram should no longer be used. > > > I will work out patches for EmulatorPkg to produce TemoraryRamDone. > > I think we should first fix TemporaryRamSupport usage. Otherwise, we are > just hiding the bug. > > Have you tried these patches to verify that they fix the issue in your setup? > Have you taken a look at the patches to see what problem is being fixed? I feel the change to PeiCore is a bit complex and introduce additional deps (assembly). Behavior of ARM and x86 becomes different. (The patch only fixes x86 issue.) Given there is no real requirement on this, I prefer to not change PeiCore. > > -Jordan > > > > > >> -Original Message- > > >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > > >> Of Ni, Ray > > >> Sent: Tuesday, February 19, 2019 10:46 AM > > >> To: Justen, Jordan L ; > > >> edk2-devel@lists.01.org > > >> Cc: Wu, Hao A ; Anthony Perard > > >> ; Laszlo Ersek ; > > >> Zeng, Star > > >> Subject: Re: [edk2] [PATCH 00/10] Fix PEI Core issue during > > >> TemporaryRamMigration > > >> > > >> Jordan, > > >> I find many real platforms do not implement the temporary ram > > >> migration PPI and rely on the PeiCore migration logic. > > >> So perhaps TemporaryRamMigration PPI was added to help platform to > > >> destroy the temporary RAM (CAR in x86 platform). > > >> But with the introduction of TemporaryRamDone PPI, maybe the > > >> TemporaryRamMigration PPI can be retired. > > >> The logic in PeiCore to call TemporaryRamMigration is just for > > >> backward compatibility. > > >> If that's true, do you still need to enhance PeiCore? > > >> > > >> For the Emulator case, I already found without > > >> TemporaryRamMigration the platform can still boot. > > >> > > >> Does OVMF hard-depend on TemporaryRamMigration? Or it can reply > on > > >> the PeiCore migration logic + TemporaryDone PPI? > > >> > > >> Thanks, > > >> Ray > > >> > > >>> -Original Message- > > >>> From: Justen, Jordan L > > >>> Sent: Monday, February 18, 2019 12:12 PM > > >>> To: edk2-devel@lists.01.org > > >>> Cc: Justen, Jordan L ; Liu Yu > > >>> ; Andrew Fish ; > Anthony > > >>> Perard ; Ard Biesheuvel > > >>> ; Wu, Hao A ; > Wang, > > >>> Jian J ; Julien Grall > > >>> ; Laszlo Ersek ; Ni, > > >>> Ray ; Zeng, Star > > >>> Subject: [PATCH 00/10] Fix PEI Core issue during > > >>> TemporaryRamMigration > > >>> > > >>> https://github.com/jljusten/edk2.git temp-ram-support > > >>> > > >>> This series fixes an issue that, while rare, is possible based on > > >>> the way the TemporaryRamSupport PPI is defined along with how it > > >>> is used by the PEI Core. > > >>> > > >>> Liu Yu reported a boot issue with EmulatorPkg, which I believe was > > >>> caused by this issue. > > >>> > > >>> The details of the issue are described in the commit message of > > >>> the > > >>> "MdeModePkg/Core/Pei: Add code path to allow assembly temp-ram > > >>> migration" patch. > > >>> > > >>> Along with this, I added a few Temporary RAM patches for > > >>> EmulatorPkg an
Re: [edk2] [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration
On 2/19/2019 9:25 PM, Gao, Liming wrote: Ray: In PI spec, TEMPORARY_RAM_SUPPORT_PPI is described as an optional PPI that is only required for platforms that may have side effects when both Temporary RAM and Permanent RAM are enabled. If a platform does not have any side effects when both Temporary RAM and Permanent RAM are enabled, and the platform is required to disable the use of Temporary RAM, then EFI_PEI_TEMPORARY_RAM_DONE should be produced. If a platform does not have any side effects when both Temporary RAM and Permanent RAM are enabled, and the platform is not required to disable the use of Temporary RAM, then neither EFI_PEI_TEMPORARY_RAM_DONE nor EFI_PEI_TEMPORARY_RAM_SUPPORT_PPI should be produced. Now, real platform has no side effect. So, only TempRamDone PPI is produced. For emulator platform, is there any side effect when both Temporary RAM and Permanent RAM are enabled? No side effect when both of T-RAM and P-RAM are enabled. Which means no side effect when neither of the PPIs is produced. But for demo purpose, I think producing TemporaryRamDone PPI makes sense. I will work out patches for EmulatorPkg to produce TemoraryRamDone. Thanks Liming -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni, Ray Sent: Tuesday, February 19, 2019 10:46 AM To: Justen, Jordan L ; edk2-devel@lists.01.org Cc: Wu, Hao A ; Anthony Perard ; Laszlo Ersek ; Zeng, Star Subject: Re: [edk2] [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration Jordan, I find many real platforms do not implement the temporary ram migration PPI and rely on the PeiCore migration logic. So perhaps TemporaryRamMigration PPI was added to help platform to destroy the temporary RAM (CAR in x86 platform). But with the introduction of TemporaryRamDone PPI, maybe the TemporaryRamMigration PPI can be retired. The logic in PeiCore to call TemporaryRamMigration is just for backward compatibility. If that's true, do you still need to enhance PeiCore? For the Emulator case, I already found without TemporaryRamMigration the platform can still boot. Does OVMF hard-depend on TemporaryRamMigration? Or it can reply on the PeiCore migration logic + TemporaryDone PPI? Thanks, Ray -Original Message- From: Justen, Jordan L Sent: Monday, February 18, 2019 12:12 PM To: edk2-devel@lists.01.org Cc: Justen, Jordan L ; Liu Yu ; Andrew Fish ; Anthony Perard ; Ard Biesheuvel ; Wu, Hao A ; Wang, Jian J ; Julien Grall ; Laszlo Ersek ; Ni, Ray ; Zeng, Star Subject: [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration https://github.com/jljusten/edk2.git temp-ram-support This series fixes an issue that, while rare, is possible based on the way the TemporaryRamSupport PPI is defined along with how it is used by the PEI Core. Liu Yu reported a boot issue with EmulatorPkg, which I believe was caused by this issue. The details of the issue are described in the commit message of the "MdeModePkg/Core/Pei: Add code path to allow assembly temp-ram migration" patch. Along with this, I added a few Temporary RAM patches for EmulatorPkg and OvmfPkg. Cc: Liu Yu Cc: Andrew Fish Cc: Anthony Perard Cc: Ard Biesheuvel Cc: Hao Wu Cc: Jian J Wang Cc: Julien Grall Cc: Laszlo Ersek Cc: Ray Ni Cc: Star Zeng Jordan Justen (10): EmulatorPkg/build.sh: Fix missing usage of -b BUILDTARGET parameter EmulatorPkg/Unix/Host: Use PcdInitValueInTempStack to init temp-ram EmulatorPkg/Sec: Replace assembly temp-ram support with C code EmulatorPkg/Sec: Disable optimizations for TemporaryRamMigration function OvmfPkg/Sec: Swap TemporaryRam Stack and Heap locations OvmfPkg/Sec: Disable optimizations for TemporaryRamMigration MdeModePkg/Core/Pei: Add code path to allow assembly temp-ram migration MdeModulePkg/Core/Pei: Use assembly for X64 TemporaryRamMigration MdeModulePkg/Core/Pei: Use assembly for IA32 TemporaryRamMigration OvmfPkg/Sec: Fill Temp Ram after TemporaryRamMigration EmulatorPkg/Sec/Ia32/SwitchRam.S | 95 --- EmulatorPkg/Sec/Ia32/SwitchRam.asm| 94 -- EmulatorPkg/Sec/Ia32/TempRam.c| 65 - EmulatorPkg/Sec/Sec.c | 76 ++- EmulatorPkg/Sec/Sec.inf | 13 +-- EmulatorPkg/Sec/X64/SwitchRam.S | 72 -- EmulatorPkg/Sec/X64/SwitchRam.asm | 76 --- EmulatorPkg/Unix/Host/Host.c | 2 +- EmulatorPkg/Unix/Host/Host.inf| 1 + EmulatorPkg/build.sh | 10 +- MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 59 .../Dispatcher/Ia32/TemporaryRamMigration.S | 72 ++ .../Ia32/TemporaryRamMigration.nasm | 78 +++ .../Pei/Dispatcher/TemporaryRamMigration.c| 52 ++ .../Dispatcher/X64/TemporaryRamMigration
Re: [edk2] [PATCH v2 1/5] MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep.
On 2/20/2019 4:16 PM, Laszlo Ersek wrote:
In the EFI_RETURN_STATUS_EXTENDED_DATA structure from PI-1.7, there may be
padding between the DataHeader and ReturnStatus members. The
REPORT_STATUS_CODE_EX() macro starts populating the structure immediately
after DataHeader, therefore the source data must provide for the padding.
Extract the BmReportImageFailure() function from EfiBootManagerBoot(),
prepare a zero padding (if any) in a temporary
EFI_RETURN_STATUS_EXTENDED_DATA object, and fix the
REPORT_STATUS_CODE_EX() macro invocation.
Cc: Dandan Bi
Cc: Hao Wu
Cc: Jian J Wang
Cc: Ray Ni
Cc: Sean Brogan
Cc: Star Zeng
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1539
Fixes: c2cf8720a5aad74230767a1f11bade2d86de3745
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek
---
Notes:
v2:
- new in v2
MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h | 1 +
MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 69 +++-
2 files changed, 52 insertions(+), 18 deletions(-)
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
index 978fbff966f6..0fef63fceedf 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
+++ b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
@@ -51,6 +51,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
EXPRESS OR IMPLIED.
#include
#include
#include
+#include
#include
#include
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index 9be1633b7480..ffb98c6c9b83 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -1667,6 +1667,55 @@ BmIsBootManagerMenuFilePath (
return FALSE;
}
+/**
+ Report status code with EFI_RETURN_STATUS_EXTENDED_DATA about LoadImage() or
+ StartImage() failure.
+
+ @param[in] ErrorCode An Error Code in the Software Class, DXE Boot
+Service Driver Subclass. ErrorCode will be used to
+compose the Value parameter for status code
+reporting. Must be one of
+EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
+EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED.
+
+ @param[in] FailureStatus The failure status returned by the boot service
+that should be reported.
+**/
+VOID
+BmReportImageFailure (
Laszlo,
Thanks for quick fixing this issue.
To match the status code it reports, how about rename the function as
"BmReportLoadFailure"?
Another minor comments in below.
+ IN UINT32 ErrorCode,
+ IN EFI_STATUS FailureStatus
+ )
+{
+ EFI_RETURN_STATUS_EXTENDED_DATA ExtendedData;
+ VOID*PaddingStart;
+ UINTN PaddingSize;
+
+ if (!ReportErrorCodeEnabled ()) {
+return;
+ }
+
+ ASSERT (
+(ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR) ||
+(ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED)
+);
+
+ PaddingStart = + 1;
+ PaddingSize = (UINTN) - (UINTN) PaddingStart;
+ ZeroMem (PaddingStart, PaddingSize);
I prefer "ZeroMem (, sizeof (ExtendedData))" instead of
introducing local variables such as PaddingStart/PaddingSize.
This makes code more good-looking:).
+ ExtendedData.ReturnStatus = FailureStatus;
+
+ REPORT_STATUS_CODE_EX (
+(EFI_ERROR_CODE | EFI_ERROR_MINOR),
+(EFI_SOFTWARE_DXE_BS_DRIVER | ErrorCode),
+0,
+NULL,
+NULL,
+PaddingStart,
+ 1
+PaddingSize + sizeof (ExtendedData.ReturnStatus)
sizeof (ExtendedData) - sizeof (ExtendedData.DataHeader)
+);
+}
+
/**
Attempt to boot the EFI boot option. This routine sets L"BootCurent" and
also signals the EFI ready to boot event. If the device path for the option
@@ -1822,15 +1871,7 @@ EfiBootManagerBoot (
//
// Report Status Code with the failure status to indicate that the
failure to load boot option
//
- REPORT_STATUS_CODE_EX (
-EFI_ERROR_CODE | EFI_ERROR_MINOR,
-(EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR),
-0,
-NULL,
-NULL,
-,
-sizeof (EFI_STATUS)
-);
+ BmReportImageFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR, Status);
BootOption->Status = Status;
//
// Destroy the RAM disk
@@ -1911,15 +1952,7 @@ EfiBootManagerBoot (
//
// Report Status Code with the failure status to indicate that boot
failure
//
-REPORT_STATUS_CODE_EX (
- EFI_ERROR_CODE | EFI_ERROR_MINOR,
- (EFI_SOFTWARE_DXE_BS_DRIVER | EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED),
- 0,
- NULL,
- NULL,
- ,
- sizeof (EFI_STATUS)
- );
+BmReportImageFailure (EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED, Status);
}
PERF_END_EX (gImageHandle,
Re: [edk2] [PATCH v1 1/1] SecurityPkg/HddPassword: Add Security feature set support for ATA dev
+
+/**
+ Entry point of the notification callback function itself within the PEIM.
+ It is to unlock HDD password for S3.
+
+ @param PeiServices Indirect reference to the PEI Services Table.
+ @param NotifyDescriptor Address of the notification descriptor data
structure.
+ @param Ppi Address of the PPI that was installed.
+
+ @return Status of the notification.
+ The status code returned from this function is ignored.
+**/
+EFI_STATUS
+EFIAPI
+HddPasswordAtaPassThruNotify (
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_NOTIFY_DESCRIPTOR *NotifyDesc,
+ IN VOID *Ppi
+ )
+{
+ HDD_PASSWORD_PEI_DRIVER_PRIVATE_DATA*Private;
+
+ DEBUG ((DEBUG_INFO, "%a() - enter at S3 resume\n", __FUNCTION__));
+
+ Private = HDD_PASSWORD_PEI_PRIVATE_DATA_FROM_THIS_NOTIFY (NotifyDesc);
+ UnlockHddPassword (Private);
Similar comments as that I gave to 13/13 OpalPasswordPei change,
we could use the 3rd parameter "Ppi" to simplify the code.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v5 13/13] SecurityPkg/OpalPassword: Remove HW init codes and consume SSC PPI
+OpalPasswordStorageSecurityPpiNotify (
+ IN EFI_PEI_SERVICES **PeiServices,
+ IN EFI_PEI_NOTIFY_DESCRIPTOR*NotifyDesc,
+ IN VOID *Ppi
)
{
- EFI_STATUSStatus;
- EFI_BOOT_MODE BootMode;
+ OPAL_PEI_DRIVER_PRIVATE_DATA*Private;
- Status = PeiServicesGetBootMode ();
- ASSERT_EFI_ERROR (Status);
- if (BootMode != BOOT_ON_S3_RESUME) {
-return EFI_UNSUPPORTED;
- }
+ DEBUG ((DEBUG_INFO, "%a entered at S3 resume!\n", __FUNCTION__));
- DEBUG ((DEBUG_INFO, "%a() - enter at S3 resume\n", __FUNCTION__));
+ Private = OPAL_PEI_PRIVATE_DATA_FROM_THIS_NOTIFY (NotifyDesc);
+ UnlockOpalPasswordDevices (Private);
In this Notify callback, we could use the 3rd parameter "Ppi" to get the
Ssc PPI instance to perform unlock operation.
With this change, the OPAL_PEI_DRIVER_PRIVATE_DATA is not needed any
more and IsSscInstanceHandled() is not needed as well.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v5 08/13] MdeModulePkg/AhciPei: Add AHCI mode ATA device support in PEI
+//
+// Check validity of the device path of the ATA AHCI controller.
+//
+Status = AhciCheckHcDevicePath (DevicePath, DevicePathLength);
1. Please avoid using "Check".
+if (EFI_ERROR (Status)) {
+ DEBUG ((
+DEBUG_ERROR, "%a: The device path is invalid for Controller %d.\n",
+__FUNCTION__, Controller
+));
+ Controller++;
+ continue;
+}
+
2. Please add more comments here.
+if (BootMode == BOOT_ON_S3_RESUME) {
+ NumberOfPorts = AhciS3GetEumeratePorts (DevicePath, DevicePathLength,
);
+ if (NumberOfPorts == 0) {
+//
+// No ports need to be enumerated for this controller.
+//
+Controller++;
+continue;
+ }
+} else {
+ PortBitMap = MAX_UINT32;
+}
+
+//
With the above comments addressed, Reviewed-by: Ray Ni
--
Thanks,
Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v5 07/13] MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox
Please add some comments above "if" to explain why the it's only skipped
in S3 boot.
With the updated comments, Reviewed-by: Ray Ni
> +if ((BootMode == BOOT_ON_S3_RESUME) &&
> +(NvmeS3SkipThisController (DevicePath, DevicePathLength))) {
> + DEBUG ((
> +DEBUG_ERROR, "%a: Controller %d is skipped during S3.\n",
> +__FUNCTION__, Controller
> +));
> + Controller++;
> + continue;
> +}
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v5 06/13] MdeModulePkg/NvmExpressPei: Add logic to produce SSC PPI
How about changing to "NvmeIsHcDevicePathValid"? "Check" in function name cannot tell what the return status means. With the change, Reviewed-by: Ray Ni ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] UefiCpuPkg/Microcode: Fix incorrect checksum issue for extended table
Reviewed-by: Ray Ni -- Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch 2/2] MdeModulePkg/BmBoot: Report status when fail to load/start boot option
Laszlo,
Thanks for catching this.
GenPerformMemoryTest() in
MdeModulePkg\Universal\MemoryTest\GenericMemoryTestDxe\LightMemoryTest.c
uses the same technics as you suggested.
I give up to propose another option: having pack(1) for the new status
structure.
> -Original Message-
> From: Laszlo Ersek
> Sent: Wednesday, February 20, 2019 9:19 AM
> To: Bi, Dandan
> Cc: edk2-devel@lists.01.org; Wu, Hao A ; Ni, Ray
>
> Subject: Re: [edk2] [patch 2/2] MdeModulePkg/BmBoot: Report status when
> fail to load/start boot option
>
> Hi Dandan,
>
> On 02/15/19 09:51, Dandan Bi wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1398
> >
> > According to PI1.7 Spec, report extended data describing an EFI_STATUS
> > return value along with EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR
> and
> > EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED status code when fail to load
> or
> > start boot option image.
> >
> > Cc: Jian J Wang
> > Cc: Hao Wu
> > Cc: Ruiyu Ni
> > Cc: Laszlo Ersek
> > Cc: Sean Brogan
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Dandan Bi
> > ---
> > .../Library/UefiBootManagerLib/BmBoot.c | 22 ++-
> > 1 file changed, 16 insertions(+), 6 deletions(-)
> >
> > diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > index 6444fb43eb..9be1633b74 100644
> > --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > @@ -1818,15 +1818,20 @@ EfiBootManagerBoot (
> >FreePool (FilePath);
> > }
> >
> > if (EFI_ERROR (Status)) {
> >//
> > - // Report Status Code to indicate that the failure to load boot
> > option
> > + // Report Status Code with the failure status to indicate that
> > + the failure to load boot option
> >//
> > - REPORT_STATUS_CODE (
> > + REPORT_STATUS_CODE_EX (
> > EFI_ERROR_CODE | EFI_ERROR_MINOR,
> > -(EFI_SOFTWARE_DXE_BS_DRIVER |
> EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR)
> > +(EFI_SOFTWARE_DXE_BS_DRIVER |
> EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR),
> > +0,
> > +NULL,
> > +NULL,
> > +,
> > +sizeof (EFI_STATUS)
> > );
> >BootOption->Status = Status;
> >//
> >// Destroy the RAM disk
> >//
> > @@ -1902,15 +1907,20 @@ EfiBootManagerBoot (
> >Status = gBS->StartImage (ImageHandle, >ExitDataSize,
> >ExitData);
> >DEBUG ((DEBUG_INFO | DEBUG_LOAD, "Image Return Status = %r\n",
> Status));
> >BootOption->Status = Status;
> >if (EFI_ERROR (Status)) {
> > //
> > -// Report Status Code to indicate that boot failure
> > +// Report Status Code with the failure status to indicate that
> > + boot failure
> > //
> > -REPORT_STATUS_CODE (
> > +REPORT_STATUS_CODE_EX (
> >EFI_ERROR_CODE | EFI_ERROR_MINOR,
> > - (EFI_SOFTWARE_DXE_BS_DRIVER |
> EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED)
> > + (EFI_SOFTWARE_DXE_BS_DRIVER |
> EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED),
> > + 0,
> > + NULL,
> > + NULL,
> > + ,
> > + sizeof (EFI_STATUS)
> >);
> >}
> >PERF_END_EX (gImageHandle, "BdsAttempt", NULL, 0, (UINT32)
> > OptionNumber);
> >
> >//
> >
>
> Unfortunately, this patch is not good; we made a mistake here.
>
> Consider the EFI_RETURN_STATUS_EXTENDED_DATA structure, added in
> patch
> #1:
>
> > typedef struct {
> > ///
> > /// The data header identifying the data:
> > /// DataHeader.HeaderSize should be sizeof(EFI_STATUS_CODE_DATA),
> > /// DataHeader.Size should be
> sizeof(EFI_RETURN_STATUS_EXTENDED_DATA) - HeaderSize,
> > /// DataHeader.Type should be EFI_STATUS_CODE_SPECIFIC_DATA_GUID.
> > ///
> > EFI_STATUS_CODE_DATA DataHeader;
> > ///
> > /// The EFI_STATUS return value of the service or function whose failure
> triggered the
> > /// reporting of the status code (generally an error code or a debug
> > code).
> > ///
> > EFI_STATUS ReturnStatus;
> > } EFI_RETURN_STATUS_EXTENDED_DATA;
>
> According to the UEFI spec, unless specified otherwise, structure members
> are aligned naturally.
>
> And, the PI spec references the UEFI spec with regard to data types.
Re: [edk2] [PATCH v2 1/2] MdePkg/UefiDevicePathLib: Add sanity check for FilePath device path
> -Original Message-
> From: Wang, Jian J
> Sent: Tuesday, February 19, 2019 6:12 PM
> To: Ni, Ray ; edk2-devel@lists.01.org
> Cc: Gao, Liming ; Kinney, Michael D
>
> Subject: RE: [PATCH v2 1/2] MdePkg/UefiDevicePathLib: Add sanity check for
> FilePath device path
>
> Hi Ray,
>
> > -----Original Message-
> > From: Ni, Ray
> > Sent: Tuesday, February 19, 2019 5:34 PM
> > To: Wang, Jian J ; edk2-devel@lists.01.org
> > Cc: Gao, Liming ; Kinney, Michael D
> >
> > Subject: RE: [PATCH v2 1/2] MdePkg/UefiDevicePathLib: Add sanity check
> > for FilePath device path
> >
> >
> >
> > > -Original Message-
> > > From: Wang, Jian J
> > > Sent: Tuesday, February 19, 2019 5:22 PM
> > > To: edk2-devel@lists.01.org
> > > Cc: Gao, Liming ; Ni, Ray ;
> > > Kinney, Michael D
> > > Subject: [PATCH v2 1/2] MdePkg/UefiDevicePathLib: Add sanity check
> > > for FilePath device path
> > >
> > > > v2: fix wrong detection of FilePath device path
> > >
> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1497
> > >
> > > Current implementation of IsDevicePathValid() is not enough for type
> > > of MEDIA_FILEPATH_DP, which has NULL-terminated string in the device
> path.
> > > This patch add a simple NULL character check at Length position.
> > >
> > > Cc: Liming Gao
> > > Cc: Ray Ni
> > > Cc: Michael D Kinney
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Jian J Wang
> > > ---
> > > MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c | 9
> > > +
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> > > b/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> > > index 5d7635fe3e..dd1bddc1c2 100644
> > > --- a/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> > > +++ b/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> > > @@ -95,6 +95,15 @@ IsDevicePathValid (
> > > return FALSE;
> > >}
> > > }
> > > +
> > > +//
> > > +// FilePath must be a NULL-terminated string.
> > > +//
> > > +if (DevicePathType (DevicePath) == MEDIA_DEVICE_PATH &&
> > > +DevicePathSubType (DevicePath) == MEDIA_FILEPATH_DP &&
> > > +*(CHAR16 *)((UINT8 *)DevicePath + NodeLength - 2) != 0) {
> > Can we assume the device path node buffer contains exact the null
> > terminated string?
> > What if the buffer contains some padding bytes after null terminated string?
> >
> > To handle this case, can we convert the DevicePath to
> > FILEPATH_DEVICE_PATH and use logic similar as below?
> >
> > FILEPATH_DEVICE_PATH *FilePath;
> > FilePath = (FILEPATH_DEVICE_PATH *) DevicePath; MaxSize = (NodeLength
> > - sizeof (EFI_DEVICE_PATH_PROTOCOL)) / sizeof (CHAR16); If (StrnLenS
> > (FilePath->PathName, MaxSize) == MaxSize) {
> > Return FALSE;
> > }
> >
>
> I did think about your implementation and I agree it might be the best way
> from
> compatibility perspective. But I have three considerations:
>
> 1. It's not a good programming habit to pass unwanted data around and should
> not
> be encouraged to do so.
> 2. It might leave potential security hole (maybe I'm a little too cautious)
> 3. The
> UEFI spec has following statement on this type of device path (ch10.3.6.4).
>
> " A NULL-terminated Path string including directory and file names. The length
> of this string n can be determined by subtracting 4 from the Length entry."
>
With such statement, I am ok to your changes.
Reviewed-by: Ray Ni
> But I'm still open to your suggestion, if all agree that compatibility is more
> important.
>
> Regards,
> Jian
>
> >
> >
> > > + return FALSE;
> > > +}
> > >}
> > >
> > >//
> > > --
> > > 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] IntelSiliconPkg/MicrocodeUpdateDxe: Error message enhancement
> -Original Message-
> From: Zhang, Shenglei
> Sent: Tuesday, February 19, 2019 3:57 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray ; Chaganty, Rangasai V
>
> Subject: [PATCH v2] IntelSiliconPkg/MicrocodeUpdateDxe: Error message
> enhancement
>
> The error message of ExtendedTableCount is not clear. Add the count
> number into the debug message.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1500
>
> v2: Change the judgment condition to return error message when
> ExtendedTableCount is not equal to target value.
>
> Cc: Ray Ni
> Cc: Rangasai V Chaganty
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> ---
> .../Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
> a/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate
> .c
> b/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate
> .c
> index 9098712c2f..037b2433a6 100644
> ---
> a/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate
> .c
> +++
> b/IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdate
> +++ .c
> @@ -517,8 +517,8 @@ VerifyMicrocode (
>// Checksum correct
>//
>ExtendedTableCount = ExtendedTableHeader-
> >ExtendedSignatureCount;
> - if (ExtendedTableCount > (ExtendedTableLength -
> sizeof(CPU_MICROCODE_EXTENDED_TABLE_HEADER)) /
> sizeof(CPU_MICROCODE_EXTENDED_TABLE)) {
> -DEBUG((DEBUG_ERROR, "VerifyMicrocode - ExtendedTableCount too
> big\n"));
> + if (ExtendedTableCount != (ExtendedTableLength -
> sizeof(CPU_MICROCODE_EXTENDED_TABLE_HEADER)) /
> sizeof(CPU_MICROCODE_EXTENDED_TABLE)) {
> +DEBUG((DEBUG_ERROR, "VerifyMicrocode - ExtendedTableCount
> + %d is incorrect\n", ExtendedTableCount));
I am not sure if changing ">" to "!=" is ok here.
Because the total size is multiple of 1024, ExtendedTableLength calculated from
the total length may contain padding bytes.
The original ">" is ok because it makes sure the extended table header doesn't
declare more entries than the ExtendedTableLength can cover.
But ExtendedTableLength may be bigger.
So I am wondering this change may cause some originally good uCode be denied.
>} else {
> ExtendedTable = (CPU_MICROCODE_EXTENDED_TABLE
> *)(ExtendedTableHeader + 1);
> for (Index = 0; Index < ExtendedTableCount; Index++) {
> --
> 2.18.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 1/2] MdePkg/UefiDevicePathLib: Add sanity check for FilePath device path
> -Original Message-
> From: Wang, Jian J
> Sent: Tuesday, February 19, 2019 5:22 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Ni, Ray ; Kinney,
> Michael D
> Subject: [PATCH v2 1/2] MdePkg/UefiDevicePathLib: Add sanity check for
> FilePath device path
>
> > v2: fix wrong detection of FilePath device path
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1497
>
> Current implementation of IsDevicePathValid() is not enough for type of
> MEDIA_FILEPATH_DP, which has NULL-terminated string in the device path.
> This patch add a simple NULL character check at Length position.
>
> Cc: Liming Gao
> Cc: Ray Ni
> Cc: Michael D Kinney
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang
> ---
> MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> b/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> index 5d7635fe3e..dd1bddc1c2 100644
> --- a/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> +++ b/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> @@ -95,6 +95,15 @@ IsDevicePathValid (
> return FALSE;
>}
> }
> +
> +//
> +// FilePath must be a NULL-terminated string.
> +//
> +if (DevicePathType (DevicePath) == MEDIA_DEVICE_PATH &&
> +DevicePathSubType (DevicePath) == MEDIA_FILEPATH_DP &&
> +*(CHAR16 *)((UINT8 *)DevicePath + NodeLength - 2) != 0) {
Can we assume the device path node buffer contains exact the null terminated
string?
What if the buffer contains some padding bytes after null terminated string?
To handle this case, can we convert the DevicePath to FILEPATH_DEVICE_PATH and
use logic similar as below?
FILEPATH_DEVICE_PATH *FilePath;
FilePath = (FILEPATH_DEVICE_PATH *) DevicePath;
MaxSize = (NodeLength - sizeof (EFI_DEVICE_PATH_PROTOCOL)) / sizeof (CHAR16);
If (StrnLenS (FilePath->PathName, MaxSize) == MaxSize) {
Return FALSE;
}
> + return FALSE;
> +}
>}
>
>//
> --
> 2.17.1.windows.2
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] UefiCpuPkg/SecCore: Wrong Debug Information for SecCore
Chasel,
Please change the two FindAndReportEntryPoints() calls in SecStartupPhase2() so
that
their line length doesn't exceed 120.
With the modification, Reviewed-by: Ray Ni
> -Original Message-
> From: Chiu, Chasel
> Sent: Tuesday, February 19, 2019 3:44 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric ; Ni, Ray ; Laszlo
> Ersek ; Chiu, Chasel
> Subject: [PATCH] UefiCpuPkg/SecCore: Wrong Debug Information for
> SecCore
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1533
>
> When SecCore and PeiCore in different FV, current implementation still
> assuming SecCore and PeiCore are in the same FV.
> To fix this issue 2 FVs will be input parameters for FindAndReportEntryPoints
> () and SecCore and PeiCore will be found in each FV and correct debug
> information will be reported.
>
> Test: Booted with internal platform successfully.
>
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu
> ---
> UefiCpuPkg/SecCore/FindPeiCore.c | 60
> ++--
> UefiCpuPkg/SecCore/SecMain.c | 10 --
> UefiCpuPkg/SecCore/SecMain.h | 8 +---
> 3 files changed, 43 insertions(+), 35 deletions(-)
>
> diff --git a/UefiCpuPkg/SecCore/FindPeiCore.c
> b/UefiCpuPkg/SecCore/FindPeiCore.c
> index bb9c434d1e..6f2046ad95 100644
> --- a/UefiCpuPkg/SecCore/FindPeiCore.c
> +++ b/UefiCpuPkg/SecCore/FindPeiCore.c
> @@ -1,7 +1,7 @@
> /** @file
>Locate the entry point for the PEI Core
>
> - Copyright (c) 2008 - 2011, Intel Corporation. All rights reserved.
> + Copyright (c) 2008 - 2019, Intel Corporation. All rights
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found at @@ -19,17 +19,17 @@
> /**
>Find core image base.
>
> - @param BootFirmwareVolumePtrPoint to the boot firmware volume.
> - @param SecCoreImageBase The base address of the SEC core image.
> - @param PeiCoreImageBase The base address of the PEI core image.
> + @param FirmwareVolumePtrPoint to the firmware volume for finding
> core image.
> + @param FileType The FileType for searching, either
> SecCore or
> PeiCore.
> + @param CoreImageBaseThe base address of the core image.
>
> **/
> EFI_STATUS
> EFIAPI
> FindImageBase (
> - IN EFI_FIRMWARE_VOLUME_HEADER *BootFirmwareVolumePtr,
> - OUT EFI_PHYSICAL_ADDRESS *SecCoreImageBase,
> - OUT EFI_PHYSICAL_ADDRESS *PeiCoreImageBase
> + IN EFI_FIRMWARE_VOLUME_HEADER *FirmwareVolumePtr,
> + IN EFI_FV_FILETYPE FileType,
> + OUT EFI_PHYSICAL_ADDRESS *CoreImageBase
>)
> {
>EFI_PHYSICAL_ADDRESSCurrentAddress;
> @@ -40,16 +40,15 @@ FindImageBase (
>EFI_COMMON_SECTION_HEADER *Section;
>EFI_PHYSICAL_ADDRESSEndOfSection;
>
> - *SecCoreImageBase = 0;
> - *PeiCoreImageBase = 0;
> + *CoreImageBase = 0;
>
> - CurrentAddress = (EFI_PHYSICAL_ADDRESS)(UINTN)
> BootFirmwareVolumePtr;
> - EndOfFirmwareVolume = CurrentAddress + BootFirmwareVolumePtr-
> >FvLength;
> + CurrentAddress = (EFI_PHYSICAL_ADDRESS)(UINTN) FirmwareVolumePtr;
> + EndOfFirmwareVolume = CurrentAddress + FirmwareVolumePtr-
> >FvLength;
>
>//
>// Loop through the FFS files in the Boot Firmware Volume
>//
> - for (EndOfFile = CurrentAddress + BootFirmwareVolumePtr-
> >HeaderLength; ; ) {
> + for (EndOfFile = CurrentAddress + FirmwareVolumePtr->HeaderLength; ;
> + ) {
>
> CurrentAddress = (EndOfFile + 7) & 0xfff8ULL;
> if (CurrentAddress > EndOfFirmwareVolume) { @@ -75,10 +74,9 @@
> FindImageBase (
> }
>
> //
> -// Look for SEC Core / PEI Core files
> +// Look for particular Core file (either SEC Core or PEI Core)
> //
> -if (File->Type != EFI_FV_FILETYPE_SECURITY_CORE &&
> -File->Type != EFI_FV_FILETYPE_PEI_CORE) {
> +if (File->Type != FileType) {
>continue;
> }
>
> @@ -115,17 +113,11 @@ FindImageBase (
>// Look for executable sections
>//
>if (Section->Type == EFI_SECTION_PE32 || Section->Type ==
> EFI_SECTION_TE) {
> -if (File->Type == EFI_FV_FILETYPE_SECURITY_CORE) {
> +if (File->Type == FileType) {
>if (IS_SECTION2 (Section)) {
> -*SecCoreImageBase = (PH
Re: [edk2] [PATCH] MdeModulePkg/PropertiesTableAttributesDxe: Remove this driver
Reviewed-by: Ray Ni
> -Original Message-
> From: Zeng, Star
> Sent: Monday, February 18, 2019 10:22 PM
> To: Wang, Jian J ; Zhang, Shenglei
> ; edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ni, Ray
> Subject: RE: [PATCH] MdeModulePkg/PropertiesTableAttributesDxe:
> Remove this driver
>
> Reviewed-by: Star Zeng
>
> -Original Message-
> From: Wang, Jian J
> Sent: Monday, February 18, 2019 10:16 PM
> To: Zhang, Shenglei ; edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ni, Ray ; Zeng,
> Star
> Subject: RE: [PATCH] MdeModulePkg/PropertiesTableAttributesDxe:
> Remove this driver
>
>
> Reviewed-by: Jian J Wang
>
> > -Original Message-
> > From: Zhang, Shenglei
> > Sent: Monday, February 18, 2019 4:53 PM
> > To: edk2-devel@lists.01.org
> > Cc: Wang, Jian J ; Wu, Hao A
> > ; Ni, Ray ; Zeng, Star
> >
> > Subject: [PATCH] MdeModulePkg/PropertiesTableAttributesDxe: Remove
> > this driver
> >
> > This functionality of this driver has been deprecated and no platform
> > employs this driver. It can be removed completely.
> > https://bugzilla.tianocore.org/show_bug.cgi?id=1475
> >
> > Cc: Jian J Wang
> > Cc: Hao Wu
> > Cc: Ray Ni
> > Cc: Star Zeng
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Shenglei Zhang
> > ---
> > MdeModulePkg/MdeModulePkg.dsc | 1 -
> > .../PropertiesTableAttributesDxe.c| 208 --
> > .../PropertiesTableAttributesDxe.inf | 56 -
> > .../PropertiesTableAttributesDxe.uni | 23 --
> > .../PropertiesTableAttributesDxeExtra.uni | 23 --
> > 5 files changed, 311 deletions(-)
> > delete mode 100644
> >
> MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAt
> t
> > ribu
> > tesDxe.c
> > delete mode 100644
> >
> MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAt
> t
> > ribu
> > tesDxe.inf
> > delete mode 100644
> >
> MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAt
> t
> > ribu
> > tesDxe.uni
> > delete mode 100644
> >
> MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAt
> t
> > ribu
> > tesDxeExtra.uni
> >
> > diff --git a/MdeModulePkg/MdeModulePkg.dsc
> > b/MdeModulePkg/MdeModulePkg.dsc index 4f2ac8ae89..388bca25bd
> 100644
> > --- a/MdeModulePkg/MdeModulePkg.dsc
> > +++ b/MdeModulePkg/MdeModulePkg.dsc
> > @@ -413,7 +413,6 @@
> >MdeModulePkg/Universal/EsrtDxe/EsrtDxe.inf
> >MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmpDxe.inf
> >
> > -
> >
> MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTableAt
> t
> > ribu
> > tesDxe.inf
> >MdeModulePkg/Universal/FileExplorerDxe/FileExplorerDxe.inf {
> >
> >
> > FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.i
> > nf
> > diff --git
> >
> a/MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTable
> A
> > ttri
> > butesDxe.c
> >
> b/MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTable
> A
> > ttri
> > butesDxe.c
> > deleted file mode 100644
> > index 4d1a46f64c..00
> > ---
> >
> a/MdeModulePkg/Universal/PropertiesTableAttributesDxe/PropertiesTable
> A
> > ttri
> > butesDxe.c
> > +++ /dev/null
> > @@ -1,208 +0,0 @@
> > -/** @file
> > - This module sets default policy for attributes of EfiACPIMemoryNVS
> > and EfiReservedMemoryType.
> > -
> > - This module sets EFI_MEMORY_XP for attributes of EfiACPIMemoryNVS
> > and EfiReservedMemoryType
> > - in UEFI memory map, if and only of PropertiesTable is published and
> > has BIT0 set.
> > -
> > -Copyright (c) 2015 - 2018, Intel Corporation. All rights
> > reserved. -This program and the accompanying materials -are
> > licensed and made available under the terms and conditions of the BSD
> > License -which accompanies this distribution. The full text of the
> > license may be found at
> > -http://opensource.org/licenses/bsd-license.php
> > -
> > -THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> > -WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR
> > IMPLIED.
> > -
> > -**/
> > -
> > -#include
> > -#include
> > -#include
> > -#include -#include
> > -#include
> > -#include -#include
> > -
> > -/**
>
Re: [edk2] [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration
Jordan, I find many real platforms do not implement the temporary ram migration PPI and rely on the PeiCore migration logic. So perhaps TemporaryRamMigration PPI was added to help platform to destroy the temporary RAM (CAR in x86 platform). But with the introduction of TemporaryRamDone PPI, maybe the TemporaryRamMigration PPI can be retired. The logic in PeiCore to call TemporaryRamMigration is just for backward compatibility. If that's true, do you still need to enhance PeiCore? For the Emulator case, I already found without TemporaryRamMigration the platform can still boot. Does OVMF hard-depend on TemporaryRamMigration? Or it can reply on the PeiCore migration logic + TemporaryDone PPI? Thanks, Ray > -Original Message- > From: Justen, Jordan L > Sent: Monday, February 18, 2019 12:12 PM > To: edk2-devel@lists.01.org > Cc: Justen, Jordan L ; Liu Yu > ; Andrew Fish ; Anthony > Perard ; Ard Biesheuvel > ; Wu, Hao A ; Wang, Jian > J ; Julien Grall ; Laszlo > Ersek > ; Ni, Ray ; Zeng, Star > > Subject: [PATCH 00/10] Fix PEI Core issue during TemporaryRamMigration > > https://github.com/jljusten/edk2.git temp-ram-support > > This series fixes an issue that, while rare, is possible based on the way the > TemporaryRamSupport PPI is defined along with how it is used by the PEI > Core. > > Liu Yu reported a boot issue with EmulatorPkg, which I believe was caused by > this issue. > > The details of the issue are described in the commit message of the > "MdeModePkg/Core/Pei: Add code path to allow assembly temp-ram > migration" patch. > > Along with this, I added a few Temporary RAM patches for EmulatorPkg and > OvmfPkg. > > Cc: Liu Yu > Cc: Andrew Fish > Cc: Anthony Perard > Cc: Ard Biesheuvel > Cc: Hao Wu > Cc: Jian J Wang > Cc: Julien Grall > Cc: Laszlo Ersek > Cc: Ray Ni > Cc: Star Zeng > > Jordan Justen (10): > EmulatorPkg/build.sh: Fix missing usage of -b BUILDTARGET parameter > EmulatorPkg/Unix/Host: Use PcdInitValueInTempStack to init temp-ram > EmulatorPkg/Sec: Replace assembly temp-ram support with C code > EmulatorPkg/Sec: Disable optimizations for TemporaryRamMigration > function > OvmfPkg/Sec: Swap TemporaryRam Stack and Heap locations > OvmfPkg/Sec: Disable optimizations for TemporaryRamMigration > MdeModePkg/Core/Pei: Add code path to allow assembly temp-ram > migration > MdeModulePkg/Core/Pei: Use assembly for X64 TemporaryRamMigration > MdeModulePkg/Core/Pei: Use assembly for IA32 TemporaryRamMigration > OvmfPkg/Sec: Fill Temp Ram after TemporaryRamMigration > > EmulatorPkg/Sec/Ia32/SwitchRam.S | 95 --- > EmulatorPkg/Sec/Ia32/SwitchRam.asm| 94 -- > EmulatorPkg/Sec/Ia32/TempRam.c| 65 - > EmulatorPkg/Sec/Sec.c | 76 ++- > EmulatorPkg/Sec/Sec.inf | 13 +-- > EmulatorPkg/Sec/X64/SwitchRam.S | 72 -- > EmulatorPkg/Sec/X64/SwitchRam.asm | 76 --- > EmulatorPkg/Unix/Host/Host.c | 2 +- > EmulatorPkg/Unix/Host/Host.inf| 1 + > EmulatorPkg/build.sh | 10 +- > MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 59 > .../Dispatcher/Ia32/TemporaryRamMigration.S | 72 ++ > .../Ia32/TemporaryRamMigration.nasm | 78 +++ > .../Pei/Dispatcher/TemporaryRamMigration.c| 52 ++ > .../Dispatcher/X64/TemporaryRamMigration.S| 69 ++ > .../Dispatcher/X64/TemporaryRamMigration.nasm | 75 +++ > MdeModulePkg/Core/Pei/PeiMain.h | 52 ++ > MdeModulePkg/Core/Pei/PeiMain.inf | 14 +++ > OvmfPkg/Sec/Ia32/SecEntry.nasm| 2 +- > OvmfPkg/Sec/SecMain.c | 59 > OvmfPkg/Sec/X64/SecEntry.nasm | 2 +- > 21 files changed, 577 insertions(+), 461 deletions(-) delete mode 100644 > EmulatorPkg/Sec/Ia32/SwitchRam.S delete mode 100644 > EmulatorPkg/Sec/Ia32/SwitchRam.asm > delete mode 100644 EmulatorPkg/Sec/Ia32/TempRam.c delete mode > 100644 EmulatorPkg/Sec/X64/SwitchRam.S delete mode 100644 > EmulatorPkg/Sec/X64/SwitchRam.asm create mode 100644 > MdeModulePkg/Core/Pei/Dispatcher/Ia32/TemporaryRamMigration.S > create mode 100644 > MdeModulePkg/Core/Pei/Dispatcher/Ia32/TemporaryRamMigration.nasm > create mode 100644 > MdeModulePkg/Core/Pei/Dispatcher/TemporaryRamMigration.c > create mode 100644 > MdeModulePkg/Core/Pei/Dispatcher/X64/TemporaryRamMigration.S > create mode 100644 > MdeModulePkg/Core/Pei/Dispatcher/X64/TemporaryRamMigration.nasm > > -- > 2.20.0.rc1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] UefiCpuPkg/Microcode: Fix incorrect checksum issue for extended table
I agree with Chao's comments.
Please add more code comments to:
1. describe the uCode format
2. explain all the 3 code blocks that checks the checksum.
> -Original Message-
> From: edk2-devel On Behalf Of Zhang,
> Chao B
> Sent: Tuesday, February 19, 2019 9:06 AM
> To: Chen, Chen A ; edk2-devel@lists.01.org
> Cc: Dong, Eric
> Subject: Re: [edk2] [PATCH] UefiCpuPkg/Microcode: Fix incorrect checksum
> issue for extended table
>
> Chen Chen:
>I think you can add uCode format info into comments. Also please highlight
> in comment Which part is header checksum calculation, which part is for
> extended header
>
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Chen A Chen
> Sent: Monday, February 18, 2019 1:54 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric
> Subject: [edk2] [PATCH] UefiCpuPkg/Microcode: Fix incorrect checksum
> issue for extended table
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1020
>
> The following Microcode payload format is define in SDM spec.
> Payload:
> |MicrocodeHeader|MicrocodeBinary|ExtendedHeader|ExtendedTable|.
> When we verify the CheckSum32 with ExtendedTable, we should use the
> fields of ExtendedTable to replace corresponding fields in MicrocodeHeader,
> and then calculate the CheckSum32 with MicrocodeHeader+MicrocodeBinary.
> This patch already verified on ICL platform.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> Cc: Ray Ni
> Cc: Eric Dong
> ---
> UefiCpuPkg/Library/MpInitLib/Microcode.c | 38
>
> 1 file changed, 29 insertions(+), 9 deletions(-)
>
> diff --git a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> index d84344c6f5..38880cdbec 100644
> --- a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> +++ b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> @@ -57,6 +57,7 @@ MicrocodeDetect (
>UINT32 LatestRevision;
>UINTN TotalSize;
>UINT32 CheckSum32;
> + UINT32 InCompleteCheckSum32;
>BOOLEAN CorrectMicrocode;
>VOID*MicrocodeData;
>MSR_IA32_PLATFORM_ID_REGISTER PlatformIdMsr;
> @@ -121,6 +122,26 @@ MicrocodeDetect (
>MicrocodeData = NULL;
>MicrocodeEnd = (UINTN) (CpuMpData->MicrocodePatchAddress +
> CpuMpData->MicrocodePatchRegionSize);
>MicrocodeEntryPoint = (CPU_MICROCODE_HEADER *) (UINTN)
> CpuMpData->MicrocodePatchAddress;
> +
> + //
> + // To avoid double calculate checksum32 value.
> + // Save the CheckSum32 of the common parts in advance.
> + //
> + if (MicrocodeEntryPoint->DataSize == 0) {
> +InCompleteCheckSum32 = CalculateSum32 (
> + (UINT32 *) MicrocodeEntryPoint,
> + sizeof (CPU_MICROCODE_HEADER) + 2000
> + );
> + } else {
> +InCompleteCheckSum32 = CalculateSum32 (
> + (UINT32 *) MicrocodeEntryPoint,
> + sizeof (CPU_MICROCODE_HEADER) +
> MicrocodeEntryPoint-
> >DataSize
> + );
> + }
> + InCompleteCheckSum32 -=
> + MicrocodeEntryPoint->ProcessorSignature.Uint32;
> + InCompleteCheckSum32 -= MicrocodeEntryPoint->ProcessorFlags;
> + InCompleteCheckSum32 -= MicrocodeEntryPoint->Checksum;
> +
>do {
> //
> // Check if the microcode is for the Cpu and the version is newer @@ -
> 137,14 +158,10 @@ MicrocodeDetect (
>MicrocodeEntryPoint->UpdateRevision > LatestRevision &&
>(MicrocodeEntryPoint->ProcessorFlags & (1 << PlatformId))
>) {
> -if (MicrocodeEntryPoint->DataSize == 0) {
> - CheckSum32 = CalculateSum32 ((UINT32 *) MicrocodeEntryPoint, 2048);
> -} else {
> - CheckSum32 = CalculateSum32 (
> - (UINT32 *) MicrocodeEntryPoint,
> - MicrocodeEntryPoint->DataSize + sizeof
> (CPU_MICROCODE_HEADER)
> - );
> -}
> +CheckSum32 = InCompleteCheckSum32;
> +CheckSum32 += MicrocodeEntryPoint->ProcessorSignature.Uint32;
> +CheckSum32 += MicrocodeEntryPoint->ProcessorFlags;
> +CheckSum32 += MicrocodeEntryPoint->Checksum;
> if (CheckSum32 == 0) {
>CorrectMicrocode = TRUE;
>ProcessorFlags = MicrocodeEntryPoint->ProcessorFlags;
> @@ -171,7 +188,10 @@ MicrocodeDetect (
>ExtendedTableCount = ExtendedTableHeader-
> >ExtendedSignatureCount;
>ExtendedTable = (CPU_MICROCODE_EXTENDED_TABLE *)
> (ExtendedTableHeader + 1);
>for (Index = 0; Index < ExtendedTableCount; Index ++) {
> -CheckSum32 = CalculateSum32 ((UINT32 *) ExtendedTable,
> sizeof(CPU_MICROCODE_EXTENDED_TABLE));
> +
Re: [edk2] [PATCH 1/2] MdeModulePkg: Add a new API ResetSystem
Zhichao,
Please separate the single patch to multiple patches so that every patch
just changes one component.
> -Original Message-
> From: Gao, Zhichao
> Sent: Monday, February 18, 2019 3:33 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray ; Gao, Liming
> Subject: [PATCH 1/2] MdeModulePkg: Add a new API ResetSystem
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1460
>
> Add a new API ResetSystem:
> VOID
> EFIAPI
> ResetSystem (
> IN EFI_RESET_TYPE ResetType,
> IN EFI_STATUS ResetStatus,
> IN UINTNDataSize,
> IN VOID *ResetData OPTIONAL
> )
> The Consumer of ResetSystemLib can use this new API to reset
> system with additional reset data.Because ResetSystemRuntimeDxe
> has a same function name with it, change the function name from
> ResetSystem to EfiRuntimeResetSystem(both ResetSystem and
> EfiResetSystem are used in ResetSystemLiband RuntimeLib, and the
> driver consumes these two library) in driver ResetSystemRuntimeDxe.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Ray Ni
> Cc: Liming Gao
> ---
> MdeModulePkg/Include/Library/ResetSystemLib.h | 25
> ++-
> .../Library/DxeResetSystemLib/DxeResetSystemLib.c | 28
> +-
> .../Library/PeiResetSystemLib/PeiResetSystemLib.c | 28
> +-
> .../Universal/ResetSystemRuntimeDxe/ResetSystem.c | 8 +++
> .../Universal/ResetSystemRuntimeDxe/ResetSystem.h | 4 ++--
> 5 files changed, 84 insertions(+), 9 deletions(-)
>
> diff --git a/MdeModulePkg/Include/Library/ResetSystemLib.h
> b/MdeModulePkg/Include/Library/ResetSystemLib.h
> index 55d1923ae1..2f5d15ade8 100644
> --- a/MdeModulePkg/Include/Library/ResetSystemLib.h
> +++ b/MdeModulePkg/Include/Library/ResetSystemLib.h
> @@ -2,7 +2,7 @@
>System reset Library Services. This library class defines a set of
>methods that reset the whole system.
>
> -Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2005 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials are licensed and made
> available under
> the terms and conditions of the BSD License that accompanies this
> distribution.
> The full text of the license may be found at
> @@ -83,4 +83,27 @@ ResetPlatformSpecific (
>IN VOID*ResetData
>);
>
> +/**
> + The ResetSystem function resets the entire platform.
> +
> + @param[in] ResetType The type of reset to perform.
> + @param[in] ResetStatusThe status code for the reset.
> + @param[in] DataSize The size, in bytes, of ResetData.
> + @param[in] ResetData For a ResetType of EfiResetCold, EfiResetWarm,
> or EfiResetShutdown
> +the data buffer starts with a Null-terminated
> string, optionally
> +followed by additional binary data. The string
> is a description
> +that the caller may use to further indicate the
> reason for the
> +system reset. ResetData is only valid if
> ResetStatus is
> something
> +other than EFI_SUCCESS unless the ResetType is
> EfiResetPlatformSpecific
> +where a minimum amount of ResetData is always
> required.
> +**/
> +VOID
> +EFIAPI
> +ResetSystem (
> + IN EFI_RESET_TYPE ResetType,
> + IN EFI_STATUS ResetStatus,
> + IN UINTNDataSize,
> + IN VOID *ResetData OPTIONAL
> + );
> +
> #endif
> diff --git
> a/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c
> b/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c
> index ea4878cab1..f5c7386c9a 100644
> --- a/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c
> +++ b/MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c
> @@ -1,7 +1,7 @@
> /** @file
>DXE Reset System Library instance that calls gRT->ResetSystem().
>
> - Copyright (c) 2017 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found at
> @@ -96,3 +96,29 @@ ResetPlatformSpecific (
> {
>gRT->ResetSystem (EfiResetPlatformSpecific, EFI_SUCCESS, DataSize,
> ResetData);
> }
> +
> +/**
> + The ResetSystem function resets th
Re: [edk2] [PATCH 2/2] MdeModulePkg: Add a runtime library instance of ResetSystemLib
Reviewed-by: Ray Ni
> -Original Message-
> From: Gao, Zhichao
> Sent: Monday, February 18, 2019 3:33 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray ; Gao, Liming
> Subject: [PATCH 2/2] MdeModulePkg: Add a runtime library instance of
> ResetSystemLib
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1461
>
> For now there is no ResetSystemLib instance that can be linked against
> Runtime driver. And it's improper to extend the existing DxeResetSystemLib
> to support Runtime driver because no one converts gRT when entering RT
> phase.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> Cc: Ray Ni
> Cc: Liming Gao
> ---
> .../RuntimeResetSystemLib/RuntimeResetSystemLib.c | 216
> +
> .../RuntimeResetSystemLib.inf | 50 +
> .../RuntimeResetSystemLib.uni | 21 ++
> 3 files changed, 287 insertions(+)
> create mode 100644
> MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.c
> create mode 100644
> MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.i
> nf
> create mode 100644
> MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib.u
> ni
>
> diff --git
> a/MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib
> .c
> b/MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib
> .c
> new file mode 100644
> index 00..17826cd6a9
> --- /dev/null
> +++
> b/MdeModulePkg/Library/RuntimeResetSystemLib/RuntimeResetSystemLib
> .c
> @@ -0,0 +1,216 @@
> +/** @file
> + DXE Reset System Library instance that calls gRT->ResetSystem().
> +
> + Copyright (c) 2017 - 2019, Intel Corporation. All rights
> + reserved. This program and the accompanying materials are
> + licensed and made available under the terms and conditions of the BSD
> + License which accompanies this distribution. The full text of the
> + license may be found at
> + http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +EFI_EVENT
> mRuntimeResetSystemLibVirtualAddressChangeEvent;
> +EFI_RUNTIME_SERVICES *mInternalRT;
> +
> +/**
> + This function causes a system-wide reset (cold reset), in which
> + all circuitry within the system returns to its initial state. This
> +type of reset
> + is asynchronous to system operation and operates without regard to
> + cycle boundaries.
> +
> + If this function returns, it means that the system does not support cold
> reset.
> +**/
> +VOID
> +EFIAPI
> +ResetCold (
> + VOID
> + )
> +{
> + mInternalRT->ResetSystem (EfiResetCold, EFI_SUCCESS, 0, NULL); }
> +
> +/**
> + This function causes a system-wide initialization (warm reset), in
> +which all processors
> + are set to their initial state. Pending cycles are not corrupted.
> +
> + If this function returns, it means that the system does not support warm
> reset.
> +**/
> +VOID
> +EFIAPI
> +ResetWarm (
> + VOID
> + )
> +{
> + mInternalRT->ResetSystem (EfiResetWarm, EFI_SUCCESS, 0, NULL); }
> +
> +/**
> + This function causes the system to enter a power state equivalent
> + to the ACPI G2/S5 or G3 states.
> +
> + If this function returns, it means that the system does not support shut
> down reset.
> +**/
> +VOID
> +EFIAPI
> +ResetShutdown (
> + VOID
> + )
> +{
> + mInternalRT->ResetSystem (EfiResetShutdown, EFI_SUCCESS, 0, NULL); }
> +
> +/**
> + This function causes the system to enter S3 and then wake up immediately.
> +
> + If this function returns, it means that the system does not support S3
> feature.
> +**/
> +VOID
> +EFIAPI
> +EnterS3WithImmediateWake (
> + VOID
> + )
> +{
> +}
> +
> +/**
> + This function causes a systemwide reset. The exact type of the reset
> +is
> + defined by the EFI_GUID that follows the Null-terminated Unicode
> +string passed
> + into ResetData. If the platform does not recognize the EFI_GUID in
> +ResetData
> + the platform must pick a supported reset type to perform.The platform
> +may
> + optionally log the parameters from any non-normal reset that occurs.
> +
> + @param[in] DataSize The size, in bytes, of ResetData.
> + @param[in] ResetData The data buffer starts with a Null-terminated
> string,
> + followed by the EFI_GUID.
> +**/
&
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
Jordan, > Study the PeiCore migration logic a bit more, I found since PeiCore > knows the exact size of new stack in permanent memory, it migrates > old stack to the top of new stack. > But the migration logic in above C code (since it doesn't know the > size of new stack, CopySize is the size of temporary memory) may copy > the old stack to the middle in new stack. Maybe your new RamMigration2 PPI needs to carry both the old and new stack/heap location and size. It helps: 1. migrate the old stack to top of new stack (instead of middle of new stack). 2. potentially reduce the size of memory that needs to be copied. TemporaryRamMigration ( IN CONST EFI_PEI_SERVICES **PeiServices, IN EFI_PHYSICAL_ADDRESS TemporaryStackBase, IN EFI_PHYSICAL_ADDRESS PermanentStackSize, IN EFI_PHYSICAL_ADDRESS TemporaryHeapBase, IN EFI_PHYSICAL_ADDRESS PermanentHeapSize, IN TEMPORARY_RAM_MIGRATION_CALLBACK Callback, IN VOID *Context ) Before the finalize of PI spec change regarding the RamMigration2 change, I prefer to fix the EmulatorPkg boot crash ASAP using the OVMF-like solution. If you agree, I will send out the patch to let you review. -- Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
On 2/16/2019 3:43 PM, Ni, Ray wrote:
(Sent third times to make sure Andrew and Laszlo are in the TO list.)
I also met this issue.
I found three solutions:
1. Forcing PeiMain CC flag to "-O0" works.
2. Changing EmulatorPkg/Sec to not produce TemporaryRamSupportPpi also
works.
3. Implement the temporary migration routine as below in EmulatorPkg/Sec
module.
EFI_STATUS
EFIAPI
SecTemporaryRamSupport (
IN CONST EFI_PEI_SERVICES **PeiServices,
IN EFI_PHYSICAL_ADDRESS TemporaryMemoryBase,
IN EFI_PHYSICAL_ADDRESS PermanentMemoryBase,
IN UINTN CopySize
)
{
VOID *OldHeap;
VOID *NewHeap;
VOID *OldStack;
VOID *NewStack;
UINTN StackMigrateOffset;
BASE_LIBRARY_JUMP_BUFFER JumpBuffer;
DEBUG ((EFI_D_INFO,
"TemporaryRamMigration(0x%Lx, 0x%Lx, 0x%Lx)\n",
TemporaryMemoryBase,
PermanentMemoryBase,
(UINT64)CopySize
));
//
// Assume Host prepare the stack and heap in the temprary ram that stack
// is below heap (stack is in smaller address).
// Stack/heap migration depends on the stack/heap location information
// in the temporary ram.
//
OldStack = (VOID*)(UINTN)TemporaryMemoryBase;
NewStack = (VOID*)((UINTN)PermanentMemoryBase);
OldHeap = (VOID*)((UINTN)TemporaryMemoryBase + (CopySize >> 1));
NewHeap = (VOID*)((UINTN)PermanentMemoryBase + (CopySize >> 1));
StackMigrateOffset = (UINTN)NewStack - (UINTN)OldStack;
//
// Migrate Heap and Stack
//
CopyMem (NewHeap, OldHeap, CopySize >> 1);
CopyMem (NewStack, OldStack, CopySize >> 1);
//
// Use SetJump()/LongJump() to switch to a new stack.
//
if (SetJump () == 0) {
#if defined (MDE_CPU_IA32)
JumpBuffer.Esp = JumpBuffer.Esp + StackMigrateOffset;
JumpBuffer.Ebp = JumpBuffer.Ebp + StackMigrateOffset;
#endif
#if defined (MDE_CPU_X64)
JumpBuffer.Rsp = JumpBuffer.Rsp + StackMigrateOffset;
JumpBuffer.Rbp = JumpBuffer.Rbp + StackMigrateOffset;
#endif
LongJump (, (UINTN)-1);
}
ZeroMem ((VOID *)(UINTN) TemporaryMemoryBase, CopySize);
return EFI_SUCCESS;
}
Andrew,
I'd like to know why you chose to produce the migration PPI from
EmulatorPkg/Sec module.
Based on PI spec and current PeiCore implementation, PeiCore can do the
migration when PPI is absent.
Study the PeiCore migration logic a bit more, I found since PeiCore
knows the exact size of new stack in permanent memory, it migrates the
old stack to the top of new stack.
But the migration logic in above C code (since it doesn't know the size
of new stack, CopySize is the size of temporary memory) may copy the old
stack to the middle in new stack.
--
Thanks,
Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
(Sent third times to make sure Andrew and Laszlo are in the TO list.)
I also met this issue.
I found three solutions:
1. Forcing PeiMain CC flag to "-O0" works.
2. Changing EmulatorPkg/Sec to not produce TemporaryRamSupportPpi also
works.
3. Implement the temporary migration routine as below in EmulatorPkg/Sec
module.
EFI_STATUS
EFIAPI
SecTemporaryRamSupport (
IN CONST EFI_PEI_SERVICES **PeiServices,
IN EFI_PHYSICAL_ADDRESS TemporaryMemoryBase,
IN EFI_PHYSICAL_ADDRESS PermanentMemoryBase,
IN UINTNCopySize
)
{
VOID *OldHeap;
VOID *NewHeap;
VOID *OldStack;
VOID *NewStack;
UINTNStackMigrateOffset;
BASE_LIBRARY_JUMP_BUFFER JumpBuffer;
DEBUG ((EFI_D_INFO,
"TemporaryRamMigration(0x%Lx, 0x%Lx, 0x%Lx)\n",
TemporaryMemoryBase,
PermanentMemoryBase,
(UINT64)CopySize
));
//
// Assume Host prepare the stack and heap in the temprary ram that stack
// is below heap (stack is in smaller address).
// Stack/heap migration depends on the stack/heap location information
// in the temporary ram.
//
OldStack = (VOID*)(UINTN)TemporaryMemoryBase;
NewStack = (VOID*)((UINTN)PermanentMemoryBase);
OldHeap = (VOID*)((UINTN)TemporaryMemoryBase + (CopySize >> 1));
NewHeap = (VOID*)((UINTN)PermanentMemoryBase + (CopySize >> 1));
StackMigrateOffset = (UINTN)NewStack - (UINTN)OldStack;
//
// Migrate Heap and Stack
//
CopyMem (NewHeap, OldHeap, CopySize >> 1);
CopyMem (NewStack, OldStack, CopySize >> 1);
//
// Use SetJump()/LongJump() to switch to a new stack.
//
if (SetJump () == 0) {
#if defined (MDE_CPU_IA32)
JumpBuffer.Esp = JumpBuffer.Esp + StackMigrateOffset;
JumpBuffer.Ebp = JumpBuffer.Ebp + StackMigrateOffset;
#endif
#if defined (MDE_CPU_X64)
JumpBuffer.Rsp = JumpBuffer.Rsp + StackMigrateOffset;
JumpBuffer.Rbp = JumpBuffer.Rbp + StackMigrateOffset;
#endif
LongJump (, (UINTN)-1);
}
ZeroMem ((VOID *)(UINTN) TemporaryMemoryBase, CopySize);
return EFI_SUCCESS;
}
Andrew,
I'd like to know why you chose to produce the migration PPI from
EmulatorPkg/Sec module.
Based on PI spec and current PeiCore implementation, PeiCore can do the
migration when PPI is absent.
--
Thanks,
Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
I also met this issue.
I found three solutions:
1. Forcing PeiMain CC flag to "-O0" works.
2. Changing EmulatorPkg/Sec to not produce TemporaryRamSupportPpi also
works.
3. Implement the temporary migration routine as below in EmulatorPkg/Sec
module.
EFI_STATUS
EFIAPI
SecTemporaryRamSupport (
IN CONST EFI_PEI_SERVICES **PeiServices,
IN EFI_PHYSICAL_ADDRESS TemporaryMemoryBase,
IN EFI_PHYSICAL_ADDRESS PermanentMemoryBase,
IN UINTNCopySize
)
{
VOID *OldHeap;
VOID *NewHeap;
VOID *OldStack;
VOID *NewStack;
UINTNStackMigrateOffset;
BASE_LIBRARY_JUMP_BUFFER JumpBuffer;
DEBUG ((EFI_D_INFO,
"TemporaryRamMigration(0x%Lx, 0x%Lx, 0x%Lx)\n",
TemporaryMemoryBase,
PermanentMemoryBase,
(UINT64)CopySize
));
//
// Assume Host prepare the stack and heap in the temprary ram that stack
// is below heap (stack is in smaller address).
// Stack/heap migration depends on the stack/heap location information
// in the temporary ram.
//
OldStack = (VOID*)(UINTN)TemporaryMemoryBase;
NewStack = (VOID*)((UINTN)PermanentMemoryBase);
OldHeap = (VOID*)((UINTN)TemporaryMemoryBase + (CopySize >> 1));
NewHeap = (VOID*)((UINTN)PermanentMemoryBase + (CopySize >> 1));
StackMigrateOffset = (UINTN)NewStack - (UINTN)OldStack;
//
// Migrate Heap and Stack
//
CopyMem (NewHeap, OldHeap, CopySize >> 1);
CopyMem (NewStack, OldStack, CopySize >> 1);
//
// Use SetJump()/LongJump() to switch to a new stack.
//
if (SetJump () == 0) {
#if defined (MDE_CPU_IA32)
JumpBuffer.Esp = JumpBuffer.Esp + StackMigrateOffset;
JumpBuffer.Ebp = JumpBuffer.Ebp + StackMigrateOffset;
#endif
#if defined (MDE_CPU_X64)
JumpBuffer.Rsp = JumpBuffer.Rsp + StackMigrateOffset;
JumpBuffer.Rbp = JumpBuffer.Rbp + StackMigrateOffset;
#endif
LongJump (, (UINTN)-1);
}
ZeroMem ((VOID *)(UINTN) TemporaryMemoryBase, CopySize);
return EFI_SUCCESS;
}
Andrew,
I'd like to know why you chose to produce the migration PPI from
EmulatorPkg/Sec module.
Based on PI spec and current PeiCore implementation, PeiCore can do the
migration when PPI is absent.
--
Thanks,
Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EmulatorPkg Unix Host Segmentation fault.
I also met this issue.
I found three solutions:
1. Forcing PeiMain CC flag to "-O0" works.
2. Changing EmulatorPkg/Sec to not produce TemporaryRamSupportPpi also
works.
3. Implement the temporary migration routine as below in EmulatorPkg/Sec
module.
EFI_STATUS
EFIAPI
SecTemporaryRamSupport (
IN CONST EFI_PEI_SERVICES **PeiServices,
IN EFI_PHYSICAL_ADDRESS TemporaryMemoryBase,
IN EFI_PHYSICAL_ADDRESS PermanentMemoryBase,
IN UINTNCopySize
)
{
VOID *OldHeap;
VOID *NewHeap;
VOID *OldStack;
VOID *NewStack;
UINTNStackMigrateOffset;
BASE_LIBRARY_JUMP_BUFFER JumpBuffer;
DEBUG ((EFI_D_INFO,
"TemporaryRamMigration(0x%Lx, 0x%Lx, 0x%Lx)\n",
TemporaryMemoryBase,
PermanentMemoryBase,
(UINT64)CopySize
));
//
// Assume Host prepare the stack and heap in the temprary ram that stack
// is below heap (stack is in smaller address).
// Stack/heap migration depends on the stack/heap location information
// in the temporary ram.
//
OldStack = (VOID*)(UINTN)TemporaryMemoryBase;
NewStack = (VOID*)((UINTN)PermanentMemoryBase);
OldHeap = (VOID*)((UINTN)TemporaryMemoryBase + (CopySize >> 1));
NewHeap = (VOID*)((UINTN)PermanentMemoryBase + (CopySize >> 1));
StackMigrateOffset = (UINTN)NewStack - (UINTN)OldStack;
//
// Migrate Heap and Stack
//
CopyMem (NewHeap, OldHeap, CopySize >> 1);
CopyMem (NewStack, OldStack, CopySize >> 1);
//
// Use SetJump()/LongJump() to switch to a new stack.
//
if (SetJump () == 0) {
#if defined (MDE_CPU_IA32)
JumpBuffer.Esp = JumpBuffer.Esp + StackMigrateOffset;
JumpBuffer.Ebp = JumpBuffer.Ebp + StackMigrateOffset;
#endif
#if defined (MDE_CPU_X64)
JumpBuffer.Rsp = JumpBuffer.Rsp + StackMigrateOffset;
JumpBuffer.Rbp = JumpBuffer.Rbp + StackMigrateOffset;
#endif
LongJump (, (UINTN)-1);
}
ZeroMem ((VOID *)(UINTN) TemporaryMemoryBase, CopySize);
return EFI_SUCCESS;
}
Andrew,
I'd like to know why you chose to produce the migration PPI from
EmulatorPkg/Sec module.
Based on PI spec and current PeiCore implementation, PeiCore can do the
migration when PPI is absent.
--
Thanks,
Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [patch 0/2] Report error status when fail to load/start boot option
Reviewed-by: Ray Ni > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo > Ersek > Sent: Friday, February 15, 2019 9:40 PM > To: Bi, Dandan ; edk2-devel@lists.01.org > Cc: Ni, Ray ; Wu, Hao A ; Gao, Liming > ; Kinney, Michael D > Subject: Re: [edk2] [patch 0/2] Report error status when fail to load/start > boot > option > > On 02/15/19 09:51, Dandan Bi wrote: > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1398 > > > > According to PI1.7, this patch series is to add the support that > > report extended data describing an EFI_STATUS return value along with > > EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and > > EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED status code when fail to load or > > start boot option image. > > > > These two commit are also available at: > > https://github.com/dandanbi/edk2/commits/ExtendedStatusCodeV1 > > > > PI1.7 is at > > https://uefi.org/sites/default/files/resources/PI_Spec_1_7_final_Jan_2 > > 019.pdf > > > > Cc: Jian J Wang > > Cc: Hao Wu > > Cc: Ruiyu Ni > > Cc: Michael D Kinney > > Cc: Liming Gao > > Cc: Laszlo Ersek > > Cc: Sean Brogan Dandan Bi (2): > > MdePkg/StatusCodeDataTypeId.h: Add new definition per PI1.7 Spec > > MdeModulePkg/BmBoot: Report status when fail to load/start boot > > option > > > > .../Library/UefiBootManagerLib/BmBoot.c | 22 ++- > > MdePkg/Include/Guid/StatusCodeDataTypeId.h| 22 ++- > > 2 files changed, 37 insertions(+), 7 deletions(-) > > > > Looks good to me. > > Reviewed-by: Laszlo Ersek > > Thank you, > Laszlo > ___ > 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
Re: [edk2] [PATCH v3 3/3] UefiCpuPkg/SecCore: Support EFI_PEI_CORE_FV_LOCATION_PPI
Reviewed-by: Ray Ni
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Chasel, Chiu
> Sent: Thursday, February 14, 2019 6:59 PM
> To: edk2-devel@lists.01.org
> Cc: Laszlo Ersek ; Dong, Eric
> Subject: [edk2] [PATCH v3 3/3] UefiCpuPkg/SecCore: Support
> EFI_PEI_CORE_FV_LOCATION_PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524
>
> EFI_PEI_CORE_FV_LOCATION_PPI may be passed by platform
> when PeiCore not in BFV so SecCore has to search PeiCore
> either from the FV location provided by
> EFI_PEI_CORE_FV_LOCATION_PPI or from BFV.
>
> Test: Verified on internal platform and booting successfully.
>
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu
> ---
> UefiCpuPkg/SecCore/SecMain.c | 35 +--
> UefiCpuPkg/SecCore/SecCore.inf | 3 ++-
> UefiCpuPkg/SecCore/SecMain.h | 3 ++-
> 3 files changed, 33 insertions(+), 8 deletions(-)
>
> diff --git a/UefiCpuPkg/SecCore/SecMain.c b/UefiCpuPkg/SecCore/SecMain.c
> index b24e190617..d84eb675f5 100644
> --- a/UefiCpuPkg/SecCore/SecMain.c
> +++ b/UefiCpuPkg/SecCore/SecMain.c
> @@ -1,7 +1,7 @@
> /** @file
>C functions in SEC
>
> - Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2008 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found
> at
> @@ -232,22 +232,45 @@ SecStartupPhase2(
>EFI_PEI_PPI_DESCRIPTOR *AllSecPpiList;
>EFI_PEI_CORE_ENTRY_POINTPeiCoreEntryPoint;
>
> + PeiCoreEntryPoint = NULL;
>SecCoreData = (EFI_SEC_PEI_HAND_OFF *) Context;
>AllSecPpiList = (EFI_PEI_PPI_DESCRIPTOR *) SecCoreData-
> >PeiTemporaryRamBase;
> +
>//
>// Find Pei Core entry point. It will report SEC and Pei Core debug
> information
> if remote debug
>// is enabled.
>//
> - FindAndReportEntryPoints ((EFI_FIRMWARE_VOLUME_HEADER *)
> SecCoreData->BootFirmwareVolumeBase, );
> - if (PeiCoreEntryPoint == NULL)
> - {
> -CpuDeadLoop ();
> + PpiList = SecPlatformMain (SecCoreData);
> + if (PpiList != NULL) {
> +for (Index = 0;
> + (PpiList[Index].Flags & EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST) !=
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST;
> + Index++) {
> + if (CompareGuid (PpiList[Index].Guid, ) &&
> (((EFI_PEI_CORE_FV_LOCATION_PPI *) PpiList[Index].Ppi)-
> >PeiCoreFvLocation != 0)) {
> +FindAndReportEntryPoints ((EFI_FIRMWARE_VOLUME_HEADER *)
> ((EFI_PEI_CORE_FV_LOCATION_PPI *) PpiList[Index].Ppi)->PeiCoreFvLocation,
> );
> +if (PeiCoreEntryPoint != NULL) {
> + break;
> +} else {
> + //
> + // PeiCore not found
> + //
> + CpuDeadLoop ();
> +}
> + }
> +}
> + }
> + //
> + // If EFI_PEI_CORE_FV_LOCATION_PPI not found, try to locate PeiCore from
> BFV.
> + //
> + if (PeiCoreEntryPoint == NULL) {
> +FindAndReportEntryPoints ((EFI_FIRMWARE_VOLUME_HEADER *)
> SecCoreData->BootFirmwareVolumeBase, );
> +if (PeiCoreEntryPoint == NULL) {
> + CpuDeadLoop ();
> +}
>}
>
>//
>// Perform platform specific initialization before entering PeiCore.
>//
> - PpiList = SecPlatformMain (SecCoreData);
>if (PpiList != NULL) {
> //
> // Remove the terminal flag from the terminal PPI
> diff --git a/UefiCpuPkg/SecCore/SecCore.inf b/UefiCpuPkg/SecCore/SecCore.inf
> index 442f663911..fc1485b5cb 100644
> --- a/UefiCpuPkg/SecCore/SecCore.inf
> +++ b/UefiCpuPkg/SecCore/SecCore.inf
> @@ -7,7 +7,7 @@
> # protected mode, setup flat memory model, enable temporary memory and
> # call into SecStartup().
> #
> -# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD
> License
> # which accompanies this distribution. The full text of the license may be
> found
> at
> @@ -73,6 +73,7 @@
>## NOTIFY
>## SOMETIMES_CONSUMES
>gPeiSecPerformancePpiGuid
> + gEfiPeiCoreFvLocationPpiGuid
>
> [Guids]
>## SOMETIMES_PRODUCES ## HOB
> diff --git a/UefiCpuPkg/SecCore/SecMain.h b/UefiCpuPkg/SecCore/SecMain.h
> index 83244af119..80045d34f4 100644
> --- a/UefiCpuPkg/SecCore/SecMain.h
> +++ b/UefiCpuPkg/SecCore/SecMain.h
> @@ -1,7 +1,7 @@
> /** @file
>Master header file for SecCore.
>
> - Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2008 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the
Re: [edk2] [PATCH v3 1/3] MdePkg: Support EFI_PEI_CORE_FV_LOCATION_PPI
Reviewed-by: Ray Ni
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Chasel, Chiu
> Sent: Thursday, February 14, 2019 6:59 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming
>
> Subject: [edk2] [PATCH v3 1/3] MdePkg: Support
> EFI_PEI_CORE_FV_LOCATION_PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524
>
> Add EFI_PEI_CORE_FV_LOCATION_PPI definition basing on PI spec 1.7, Section
> 6.3.9.
> This PPI can support the secnario that PEI Foundation not in BFV.
>
> Cc: Michael D Kinney
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu
> ---
> MdePkg/Include/Ppi/PeiCoreFvLocation.h | 48
>
> MdePkg/MdePkg.dec | 11 +--
> 2 files changed, 57 insertions(+), 2 deletions(-)
>
> diff --git a/MdePkg/Include/Ppi/PeiCoreFvLocation.h
> b/MdePkg/Include/Ppi/PeiCoreFvLocation.h
> new file mode 100644
> index 00..3bea6819ec
> --- /dev/null
> +++ b/MdePkg/Include/Ppi/PeiCoreFvLocation.h
> @@ -0,0 +1,48 @@
> +/** @file
> + Header file for Pei Core FV Location PPI.
> +
> + This PPI contains a pointer to the firmware volume which contains the PEI
> Foundation.
> + If the PEI Foundation does not reside in the BFV, then SEC must pass
> + this PPI as a part of the PPI list provided to the PEI Foundation
> + Entry Point, otherwise the PEI Foundation shall assume that it resides
> within
> the BFV.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved. This
> + program and the accompanying materials are licensed and made
> + available under the terms and conditions of the BSD License which
> + accompanies this distribution. The full text of the license may be
> + found at http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> + @par Revision Reference:
> + This PPI is defined in UEFI Platform Initialization Specification 1.7
> Volume 1:
> + Standards
> +
> +**/
> +
> +
> +#ifndef _EFI_PEI_CORE_FV_LOCATION_H_
> +#define _EFI_PEI_CORE_FV_LOCATION_H_
> +
> +///
> +/// Global ID for EFI_PEI_CORE_FV_LOCATION_PPI /// #define
> +EFI_PEI_CORE_FV_LOCATION_GUID \
> + { \
> +0x52888eae, 0x5b10, 0x47d0, {0xa8, 0x7f, 0xb8, 0x22, 0xab, 0xa0,
> +0xca, 0xf4 } \
> + }
> +
> +///
> +/// This PPI provides location of EFI PeiCoreFv.
> +///
> +typedef struct {
> + ///
> + /// Pointer to the first byte of the firmware volume which contains the PEI
> Foundation.
> + ///
> + VOID*PeiCoreFvLocation;
> +} EFI_PEI_CORE_FV_LOCATION_PPI;
> +
> +extern EFI_GUID gEfiPeiCoreFvLocationPpiGuid;
> +
> +#endif // _EFI_PEI_CORE_FV_LOCATION_H_
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index
> a485408310..c859b4a511 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -2,9 +2,9 @@
> # This Package provides all definitions, library classes and libraries
> instances.
> #
> # It also provides the definitions(including PPIs/PROTOCOLs/GUIDs) of -#
> EFI1.10/UEFI2.7/PI1.6 and some Industry Standards.
> +# EFI1.10/UEFI2.7/PI1.7 and some Industry Standards.
> #
> -# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2007 - 2019, Intel Corporation. All rights
> +reserved.
> # Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved. #
> (C)
> Copyright 2016 Hewlett Packard Enterprise Development LP # @@ -929,6
> +929,13 @@
>## Include/Ppi/SecHobData.h
>gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4, 0xee, 0xf5,
> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
>
> + #
> + # PPIs defined in PI 1.7.
> + #
> +
> + ## Include/Ppi/PeiCoreFvLocation.h
> + gEfiPeiCoreFvLocationPpiGuid = { 0x52888eae, 0x5b10, 0x47d0, { 0xa8,
> 0x7f,
> 0xb8, 0x22, 0xab, 0xa0, 0xca, 0xf4 }}
> +
> [Protocols]
>## Include/Protocol/Pcd.h
>gPcdProtocolGuid = { 0x11B34006, 0xD85B, 0x4D0A, { 0xA2,
> 0x90,
> 0xD5, 0xA5, 0x71, 0x31, 0x0E, 0xF7 }}
> --
> 2.13.3.windows.1
>
> ___
> 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
Re: [edk2] [PATCH v3 2/3] MdeModulePkg/PeiMain: Support EFI_PEI_CORE_FV_LOCATION_PPI
Reviewed-by: Ray Ni
> -Original Message-
> From: Chiu, Chasel
> Sent: Thursday, February 14, 2019 6:59 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray ; Zeng, Star ; Gao, Liming
> ; Chiu, Chasel
> Subject: [PATCH v3 2/3] MdeModulePkg/PeiMain: Support
> EFI_PEI_CORE_FV_LOCATION_PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524
>
> When shadowing PeiCore the EFI_PEI_CORE_FV_LOCATION_PPI should be
> checked to see if PeiCore not in BFV, otherwise just shadowing PeiCore from
> BFV.
>
> Test: Verified on internal platform and booting successfully.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu
> ---
> MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 53
> -
> MdeModulePkg/Core/Pei/PeiMain.h | 3 ++-
> MdeModulePkg/Core/Pei/PeiMain.inf | 3 ++-
> 3 files changed, 44 insertions(+), 15 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> index 4da80a8222..a7da90e149 100644
> --- a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> +++ b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> @@ -1,7 +1,7 @@
> /** @file
>Pei Core Main Entry Point
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials are licensed and made available
> under the terms and conditions of the BSD License which accompanies this
> distribution. The full text of the license may be found at @@ -80,22 +80,49
> @@
> ShadowPeiCore (
>IN PEI_CORE_INSTANCE *PrivateData
>)
> {
> - EFI_PEI_FILE_HANDLE PeiCoreFileHandle;
> - EFI_PHYSICAL_ADDRESS EntryPoint;
> - EFI_STATUS Status;
> - UINT32 AuthenticationState;
> + EFI_PEI_FILE_HANDLE PeiCoreFileHandle;
> + EFI_PHYSICAL_ADDRESS EntryPoint;
> + EFI_STATUS Status;
> + UINT32 AuthenticationState;
> + UINTNIndex;
> + EFI_PEI_CORE_FV_LOCATION_PPI *PeiCoreFvLocationPpi;
> + UINTNPeiCoreFvIndex;
>
>PeiCoreFileHandle = NULL;
> -
>//
> - // Find the PEI Core in the BFV
> + // Default PeiCore is in BFV
> + //
> + PeiCoreFvIndex = 0;
> + //
> + // Find the PEI Core either from EFI_PEI_CORE_FV_LOCATION_PPI
> + indicated FV or BFV // Status = PeiServicesLocatePpi (
> + ,
> + 0,
> + NULL,
> + (VOID **)
> + );
> + if (!EFI_ERROR (Status) && (PeiCoreFvLocationPpi->PeiCoreFvLocation !=
> NULL)) {
> +//
> +// If PeiCoreFvLocation present, the PEI Core should be found from
> indicated
> FV
> +//
> +for (Index = 0; Index < PrivateData->FvCount; Index ++) {
> + if (PrivateData->Fv[Index].FvHandle == PeiCoreFvLocationPpi-
> >PeiCoreFvLocation) {
> +PeiCoreFvIndex = Index;
> +break;
> + }
> +}
> +ASSERT (Index < PrivateData->FvCount); } // // Find PEI Core
> + from the given FV index
>//
> - Status = PrivateData->Fv[0].FvPpi->FindFileByType (
> - PrivateData->Fv[0].FvPpi,
> - EFI_FV_FILETYPE_PEI_CORE,
> - PrivateData->Fv[0].FvHandle,
> -
> - );
> + Status = PrivateData->Fv[PeiCoreFvIndex].FvPpi->FindFileByType (
> +
> PrivateData->Fv[PeiCoreFvIndex].FvPpi,
> +EFI_FV_FILETYPE_PEI_CORE,
> +
> PrivateData->Fv[PeiCoreFvIndex].FvHandle,
> +
> +);
>ASSERT_EFI_ERROR (Status);
>
>//
> diff --git a/MdeModulePkg/Core/Pei/PeiMain.h
> b/MdeModulePkg/Core/Pei/PeiMain.h index 322e7cd845..a61da73fd8 100644
> --- a/MdeModulePkg/Core/Pei/PeiMain.h
> +++ b/MdeModulePkg/Core/Pei/PeiMain.h
> @@ -1,7 +1,7 @@
> /** @file
>Definition of Pei Core Structures and Services
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials are licen
Re: [edk2] [Patch 0/3] Simplify CPU Features solution.
Eric, Please update the copyright year to 2019 for every file you changed. > -Original Message- > From: Dong, Eric > Sent: Wednesday, February 13, 2019 10:04 AM > To: edk2-devel@lists.01.org > Cc: Ni, Ray ; Laszlo Ersek > Subject: [Patch 0/3] Simplify CPU Features solution. > > Changes includes: > 1. Optimize PCD PcdCpuFeaturesUserConfiguration 2. Limit useage of > PcdCpuFeaturesSupport 3. Remove some useless APIs. > Detail explanation please check each patch's introduction. > > Cc: Ray Ni > Cc: Laszlo Ersek > > Eric Dong (3): > UefiCpuPkg/RegisterCpuFeaturesLib: Remove useless functions. > UefiCpuPkg/RegisterCpuFeaturesLib: Optimize PCD > PcdCpuFeaturesUserConfiguration. > UefiCpuPkg/RegisterCpuFeaturesLib: Simplify PcdCpuFeaturesSupport. > > .../Include/Library/RegisterCpuFeaturesLib.h | 34 > .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 95 - > - > .../DxeRegisterCpuFeaturesLib.inf | 1 - > .../PeiRegisterCpuFeaturesLib.inf | 1 - > .../RegisterCpuFeaturesLib/RegisterCpuFeatures.h | 2 - > .../RegisterCpuFeaturesLib.c | 60 ++ > UefiCpuPkg/UefiCpuPkg.dec | 7 +- > 7 files changed, 42 insertions(+), 158 deletions(-) > > -- > 2.15.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 3/3] UefiCpuPkg/RegisterCpuFeaturesLib: Simplify PcdCpuFeaturesSupport.
Reviewed-by: Ray Ni
On 2/13/2019 10:04 AM, Eric Dong wrote:
PcdCpuFeaturesSupport used to specify the platform policy about
what CPU features this platform supports. This value is decide by
platform owner, not by hardware. After this change, this PCD will
be used in IsCpuFeatureSupported function only.
Now RegisterCpuFeaturesLib use this PCD as an template to Get the
pcd size. Update the code logic to replace it with
PcdCpuFeaturesSetting.
BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1375
Cc: Ray Ni
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong
---
.../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 66 +++---
.../RegisterCpuFeaturesLib/RegisterCpuFeatures.h | 1 -
.../RegisterCpuFeaturesLib.c | 10 ++--
3 files changed, 24 insertions(+), 53 deletions(-)
diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
index 4ebd0025b4..762eaec277 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
@@ -74,27 +74,6 @@ GetSettingPcd (
return SettingBitMask;
}
-/**
- Worker function to get PcdCpuFeaturesSupport.
-
- @return The pointer to CPU feature bits mask buffer.
-**/
-UINT8 *
-GetSupportPcd (
- VOID
- )
-{
- UINT8 *SupportBitMask;
-
- SupportBitMask = AllocateCopyPool (
- PcdGetSize (PcdCpuFeaturesSupport),
- PcdGetPtr (PcdCpuFeaturesSupport)
- );
- ASSERT (SupportBitMask != NULL);
-
- return SupportBitMask;
-}
-
/**
Collects CPU type and feature information.
@@ -282,11 +261,6 @@ CpuInitDataInitialize (
ASSERT (CpuFeaturesData->CpuFlags.CoreSemaphoreCount != NULL);
CpuFeaturesData->CpuFlags.PackageSemaphoreCount = AllocateZeroPool (sizeof (UINT32)
* CpuStatus->PackageCount * CpuStatus->MaxCoreCount * CpuStatus->MaxThreadCount);
ASSERT (CpuFeaturesData->CpuFlags.PackageSemaphoreCount != NULL);
-
- //
- // Get support and configuration PCDs
- //
- CpuFeaturesData->SupportPcd = GetSupportPcd ();
}
/**
@@ -306,7 +280,7 @@ SupportedMaskOr (
UINT8 *Data1;
UINT8 *Data2;
- BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
+ BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
Data1 = SupportedFeatureMask;
Data2 = OrFeatureBitMask;
for (Index = 0; Index < BitMaskSize; Index++) {
@@ -331,7 +305,7 @@ SupportedMaskAnd (
UINT8 *Data1;
UINT8 *Data2;
- BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
+ BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
Data1 = SupportedFeatureMask;
Data2 = AndFeatureBitMask;
for (Index = 0; Index < BitMaskSize; Index++) {
@@ -356,7 +330,7 @@ SupportedMaskCleanBit (
UINT8 *Data1;
UINT8 *Data2;
- BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
+ BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
Data1 = SupportedFeatureMask;
Data2 = AndFeatureBitMask;
for (Index = 0; Index < BitMaskSize; Index++) {
@@ -387,7 +361,7 @@ IsBitMaskMatch (
UINT8 *Data1;
UINT8 *Data2;
- BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
+ BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
Data1 = SupportedFeatureMask;
Data2 = ComparedFeatureBitMask;
@@ -426,22 +400,22 @@ CollectProcessorData (
Entry = GetFirstNode (>FeatureList);
while (!IsNull (>FeatureList, Entry)) {
CpuFeature = CPU_FEATURE_ENTRY_FROM_LINK (Entry);
-if (IsBitMaskMatch (CpuFeaturesData->SupportPcd, CpuFeature->FeatureMask))
{
- if (CpuFeature->SupportFunc == NULL) {
-//
-// If SupportFunc is NULL, then the feature is supported.
-//
-SupportedMaskOr (
- CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
- CpuFeature->FeatureMask
- );
- } else if (CpuFeature->SupportFunc (ProcessorNumber, CpuInfo,
CpuFeature->ConfigData)) {
-SupportedMaskOr (
- CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
- CpuFeature->FeatureMask
- );
- }
+
+if (CpuFeature->SupportFunc == NULL) {
+ //
+ // If SupportFunc is NULL, then the feature is supported.
+ //
+ SupportedMaskOr (
+CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
+CpuFeature->FeatureMask
+);
+} else if (CpuFeature->SupportFunc (ProcessorNumber, CpuInfo,
CpuFeature->ConfigData)) {
+ SupportedMaskOr (
+CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
+CpuFeature->FeatureMask
+);
}
+
Entry = Entry->ForwardLink;
}
}
@@ -646,8 +620,6 @@ AnalysisProcessorFeatures (
DumpCpuFeature
Re: [edk2] [Patch 2/3] UefiCpuPkg/RegisterCpuFeaturesLib: Optimize PCD PcdCpuFeaturesUserConfiguration.
> -Original Message-
> From: Dong, Eric
> Sent: Wednesday, February 13, 2019 10:04 AM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray ; Laszlo Ersek
> Subject: [Patch 2/3] UefiCpuPkg/RegisterCpuFeaturesLib: Optimize PCD
> PcdCpuFeaturesUserConfiguration.
>
> In current implementation, PCD PcdCpuFeaturesUserConfiguration used as
> user enabled CPU features list. It is initialzied in platform driver and as an
> input for CpuFeatures driver. PCD PcdCpuFeaturesSetting used as an output
> for the final enabled CPU features list. For now,
> PcdCpuFeaturesUserConfiguration is only used as an input and
> PcdCpuFeaturesSetting only used as an output.
>
> This change merge PcdCpuFeaturesUserConfiguration into
> PcdCpuFeaturesSetting.
> Use PcdCpuFeaturesSetting as input for the user input feature setting Use
> PcdCpuFeaturesSetting as output for the final CPU feature setting
>
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1375
>
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong
> ---
> .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 37 --
>
> .../DxeRegisterCpuFeaturesLib.inf | 1 -
> .../PeiRegisterCpuFeaturesLib.inf | 1 -
> .../RegisterCpuFeaturesLib/RegisterCpuFeatures.h | 1 -
> UefiCpuPkg/UefiCpuPkg.dec | 7 ++--
> 5 files changed, 22 insertions(+), 25 deletions(-)
>
> diff --git
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> index bae92b89a6..4ebd0025b4 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> @@ -54,41 +54,41 @@ SetSettingPcd (
> }
>
> /**
> - Worker function to get PcdCpuFeaturesSupport.
> + Worker function to get PcdCpuFeaturesSetting.
>
>@return The pointer to CPU feature bits mask buffer.
> **/
> UINT8 *
> -GetSupportPcd (
> +GetSettingPcd (
>VOID
>)
> {
> - UINT8 *SupportBitMask;
> + UINT8 *SettingBitMask;
>
> - SupportBitMask = AllocateCopyPool (
> - PcdGetSize (PcdCpuFeaturesSupport),
> - PcdGetPtr (PcdCpuFeaturesSupport)
> + SettingBitMask = AllocateCopyPool (
> + PcdGetSize (PcdCpuFeaturesSetting),
> + PcdGetPtr (PcdCpuFeaturesSetting)
>);
> - ASSERT (SupportBitMask != NULL);
> + ASSERT (SettingBitMask != NULL);
>
> - return SupportBitMask;
> + return SettingBitMask;
> }
>
> /**
> - Worker function to get PcdCpuFeaturesUserConfiguration.
> + Worker function to get PcdCpuFeaturesSupport.
>
>@return The pointer to CPU feature bits mask buffer.
> **/
> UINT8 *
> -GetConfigurationPcd (
> +GetSupportPcd (
>VOID
>)
> {
>UINT8 *SupportBitMask;
>
>SupportBitMask = AllocateCopyPool (
> - PcdGetSize (PcdCpuFeaturesUserConfiguration),
> - PcdGetPtr (PcdCpuFeaturesUserConfiguration)
> + PcdGetSize (PcdCpuFeaturesSupport),
> + PcdGetPtr (PcdCpuFeaturesSupport)
>);
>ASSERT (SupportBitMask != NULL);
>
> @@ -287,7 +287,6 @@ CpuInitDataInitialize (
>// Get support and configuration PCDs
>//
>CpuFeaturesData->SupportPcd = GetSupportPcd ();
> - CpuFeaturesData->ConfigurationPcd = GetConfigurationPcd (); }
>
> /**
> @@ -595,6 +594,9 @@ AnalysisProcessorFeatures (
>CPU_FEATURE_DEPENDENCE_TYPE AfterDep;
>CPU_FEATURE_DEPENDENCE_TYPE NoneNeibBeforeDep;
>CPU_FEATURE_DEPENDENCE_TYPE NoneNeibAfterDep;
> + UINT8*ConfigurationPcd;
1. Can we use the name "SettingPcd"? To use the same term.
> +
> + ConfigurationPcd = NULL;
>
>CpuFeaturesData = GetCpuFeaturesData ();
>CpuFeaturesData->CapabilityPcd = AllocatePool (CpuFeaturesData-
> >BitMaskSize); @@ -610,10 +612,13 @@ AnalysisProcessorFeatures (
>//
>// Calculate the last setting
>//
> -
>CpuFeaturesData->SettingPcd = AllocateCopyPool (CpuFeaturesData-
> >BitMaskSize, CpuFeaturesData->CapabilityPcd);
>ASSERT (CpuFeaturesData->SettingPcd != NULL);
> - SupportedMaskAnd (CpuFeaturesData->SettingPcd, CpuFeaturesData-
> >ConfigurationPcd);
> + ConfigurationPcd = GetSettingPcd ();
2. SuportedMaskAnd() function doesn't change the parameter 2.
So how about we pass PcdGetPtr (PcdCpuFeaturesSetting) directly to
SupportedMaskAnd()?
> + SupportedMaskAnd (C
Re: [edk2] [PATCH v2 3/3] UefiCpuPkg/SecCore: Support EFI_PEI_CORE_FV_LOCATION_PPI
> -Original Message-
> From: Chiu, Chasel
> Sent: Wednesday, February 13, 2019 5:47 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric ; Ni, Ray ; Laszlo
> Ersek ; Chiu, Chasel
> Subject: [PATCH v2 3/3] UefiCpuPkg/SecCore: Support
> EFI_PEI_CORE_FV_LOCATION_PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524
>
> EFI_PEI_CORE_FV_LOCATION_PPI may be passed by platform when PeiCore
> not in BFV so SecCore has to search PeiCore either from the FV location
> provided by EFI_PEI_CORE_FV_LOCATION_PPI or from BFV.
>
> Test: Verified on internal platform and booting successfully.
>
> Cc: Eric Dong
> Cc: Ray Ni
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu
> ---
> UefiCpuPkg/SecCore/SecMain.c | 35
> +--
> UefiCpuPkg/SecCore/SecCore.inf | 3 ++-
> UefiCpuPkg/SecCore/SecMain.h | 3 ++-
> 3 files changed, 33 insertions(+), 8 deletions(-)
>
> diff --git a/UefiCpuPkg/SecCore/SecMain.c
> b/UefiCpuPkg/SecCore/SecMain.c index b24e190617..b99072599d 100644
> --- a/UefiCpuPkg/SecCore/SecMain.c
> +++ b/UefiCpuPkg/SecCore/SecMain.c
> @@ -1,7 +1,7 @@
> /** @file
>C functions in SEC
>
> - Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2008 - 2019, Intel Corporation. All rights
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found at @@ -228,26 +228,49 @@ SecStartupPhase2( {
>EFI_SEC_PEI_HAND_OFF*SecCoreData;
>EFI_PEI_PPI_DESCRIPTOR *PpiList;
> + EFI_PEI_PPI_DESCRIPTOR *PpiListTmp;
1. Maybe this local variable is not needed. We can use PpiList[Index].
>UINT32 Index;
>EFI_PEI_PPI_DESCRIPTOR *AllSecPpiList;
>EFI_PEI_CORE_ENTRY_POINTPeiCoreEntryPoint;
>
> + PeiCoreEntryPoint = NULL;
>SecCoreData = (EFI_SEC_PEI_HAND_OFF *) Context;
>AllSecPpiList = (EFI_PEI_PPI_DESCRIPTOR *) SecCoreData-
> >PeiTemporaryRamBase;
> +
>//
>// Find Pei Core entry point. It will report SEC and Pei Core debug
> information if remote debug
>// is enabled.
>//
> - FindAndReportEntryPoints ((EFI_FIRMWARE_VOLUME_HEADER *)
> SecCoreData->BootFirmwareVolumeBase, );
> - if (PeiCoreEntryPoint == NULL)
> - {
> -CpuDeadLoop ();
> + PpiList = SecPlatformMain (SecCoreData); PpiListTmp = PpiList; for
> + (;;) {
2. Similar comments as above. Maybe we can just use PpiList[Index] in the loop.
By the way, original code logic checks PpiList against NULL.
Do we still need to make sure to deference PpiList after checking against NULL?
> +if (CompareGuid (PpiListTmp->Guid, ) &&
> (((EFI_PEI_CORE_FV_LOCATION_PPI *) PpiListTmp->Ppi)-
> >PeiCoreFvLocation != 0)) {
> + FindAndReportEntryPoints ((EFI_FIRMWARE_VOLUME_HEADER *)
> ((EFI_PEI_CORE_FV_LOCATION_PPI *) PpiListTmp->Ppi)->PeiCoreFvLocation,
> );
> + if (PeiCoreEntryPoint != NULL) {
> +break;
3. Is it valid that PeiCore cannot be found in the PeiCoreFvLocation?
If no, can we just dead-loop here when PeiCoreEntryPoint is NULL?
> + }
> +}
> +if ((PpiListTmp->Flags & EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST) ==
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST) {
> + //
> + // Continue until the end of the PPI List.
> + //
> + break;
> +}
> +PpiListTmp++;
> + }
> + //
> + // If EFI_PEI_CORE_FV_LOCATION_PPI not found or no PeiCore found by
> the pointer in provided PPI, try to locate PeiCore from BFV.
> + //
> + if (PeiCoreEntryPoint == NULL) {
> +FindAndReportEntryPoints ((EFI_FIRMWARE_VOLUME_HEADER *)
> SecCoreData->BootFirmwareVolumeBase, );
> +if (PeiCoreEntryPoint == NULL) {
> + CpuDeadLoop ();
> +}
>}
>
>//
>// Perform platform specific initialization before entering PeiCore.
>//
> - PpiList = SecPlatformMain (SecCoreData);
>if (PpiList != NULL) {
> //
> // Remove the terminal flag from the terminal PPI diff --git
> a/UefiCpuPkg/SecCore/SecCore.inf b/UefiCpuPkg/SecCore/SecCore.inf
> index 442f663911..fc1485b5cb 100644
> --- a/UefiCpuPkg/SecCore/SecCore.inf
> +++ b/UefiCpuPkg/SecCore/SecCore.inf
> @@ -7,7 +7,7 @@
> # protected mode, setup flat memory model, enable temporary memory
> and # call into SecStartup().
> #
> -# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2006 - 2019, Intel Corporation.
Re: [edk2] [PATCH 2/3] MdeModulePkg/PeiMain: Support EFI_PEI_CORE_FV_LOCATION_PPI
Sorry, please ignore my other review mail and just check this mail.
3 minor comments below.
> -Original Message-
> From: Chiu, Chasel
> Sent: Tuesday, February 12, 2019 9:20 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray ; Zeng, Star ; Gao, Liming
> ; Chiu, Chasel
> Subject: [PATCH 2/3] MdeModulePkg/PeiMain: Support
> EFI_PEI_CORE_FV_LOCATION_PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524
>
> When shadowing PeiCore the EFI_PEI_CORE_FV_LOCATION_PPI should be
> checked to see if PeiCore not in BFV, otherwise just shadowing PeiCore from
> BFV.
>
> Test: Verified on internal platform and booting successfully.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu
> ---
> MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 58
> +-
> MdeModulePkg/Core/Pei/PeiMain.h | 3 ++-
> MdeModulePkg/Core/Pei/PeiMain.inf | 3 ++-
> 3 files changed, 49 insertions(+), 15 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> index 4da80a8222..408f24c216 100644
> --- a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> +++ b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> @@ -1,7 +1,7 @@
> /** @file
>Pei Core Main Entry Point
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials are licensed and made
> available under the terms and conditions of the BSD License which
> accompanies this distribution. The full text of the license may be found at
> @@ -80,23 +80,55 @@ ShadowPeiCore (
>IN PEI_CORE_INSTANCE *PrivateData
>)
> {
> - EFI_PEI_FILE_HANDLE PeiCoreFileHandle;
> - EFI_PHYSICAL_ADDRESS EntryPoint;
> - EFI_STATUS Status;
> - UINT32 AuthenticationState;
> + EFI_PEI_FILE_HANDLE PeiCoreFileHandle;
> + EFI_PHYSICAL_ADDRESS EntryPoint;
> + EFI_STATUS Status;
> + UINT32 AuthenticationState;
> + UINTNIndex;
> + EFI_PEI_CORE_FV_LOCATION_PPI *PeiCoreFvLocationPpi;
>
>PeiCoreFileHandle = NULL;
>
>//
> - // Find the PEI Core in the BFV
> + // Find the PEI Core either from EFI_PEI_CORE_FV_LOCATION_PPI
> + indicated FV or BFV
>//
> - Status = PrivateData->Fv[0].FvPpi->FindFileByType (
> - PrivateData->Fv[0].FvPpi,
> - EFI_FV_FILETYPE_PEI_CORE,
> - PrivateData->Fv[0].FvHandle,
> -
> - );
> - ASSERT_EFI_ERROR (Status);
> + Status = PeiServicesLocatePpi (
> + ,
> + 0,
> + NULL,
> + (VOID **)
> + );
> + if (!EFI_ERROR (Status) && (PeiCoreFvLocationPpi->PeiCoreFvLocation !=
> NULL)) {
> +//
> +// If PeiCoreFvLocation present, the PEI Core should be found from
> indicated FV.
> +//
> +for (Index = 0; Index < PrivateData->FvCount; Index ++) {
> + if ((UINT32) PrivateData->Fv[Index].FvHandle != (UINT32)
> PeiCoreFvLocationPpi->PeiCoreFvLocation) {
> +continue;
> + }
> + Status = PrivateData->Fv[Index].FvPpi->FindFileByType (
> + PrivateData->Fv[Index].FvPpi,
> + EFI_FV_FILETYPE_PEI_CORE,
> +
> PrivateData->Fv[Index].FvHandle,
> +
> + );
> + if (!EFI_ERROR (Status)) {
> +break;
1. Is it valid that PEI_CORE cannot be found in the PeiCoreFvLocation?
If no, why not assert here?
> + }
> +}
> +ASSERT (Index < PrivateData->FvCount); } else {
> +//
> +// Find PEI Core from BFV
> +//
> +Status = PrivateData->Fv[0].FvPpi->FindFileByType (
> + PrivateData->Fv[0].FvPpi,
> + EFI_FV_FILETYPE_PEI_CORE,
> + PrivateData->Fv[0].FvHandle,
> +
> + );
> +ASSERT_EFI_ERROR (Status);
2. Seems to have code duplication here. Can we have a local
Re: [edk2] [PATCH 2/3] MdeModulePkg/PeiMain: Support EFI_PEI_CORE_FV_LOCATION_PPI
1. please move the #include adjacent to other #include
2. Can you explain why
> -Original Message-
> From: Chiu, Chasel
> Sent: Tuesday, February 12, 2019 9:20 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray ; Zeng, Star ; Gao, Liming
> ; Chiu, Chasel
> Subject: [PATCH 2/3] MdeModulePkg/PeiMain: Support
> EFI_PEI_CORE_FV_LOCATION_PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524
>
> When shadowing PeiCore the EFI_PEI_CORE_FV_LOCATION_PPI should be
> checked to see if PeiCore not in BFV, otherwise just shadowing PeiCore from
> BFV.
>
> Test: Verified on internal platform and booting successfully.
>
> Cc: Jian J Wang
> Cc: Hao Wu
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu
> ---
> MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 58
> +-
> MdeModulePkg/Core/Pei/PeiMain.h | 3 ++-
> MdeModulePkg/Core/Pei/PeiMain.inf | 3 ++-
> 3 files changed, 49 insertions(+), 15 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> index 4da80a8222..408f24c216 100644
> --- a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> +++ b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> @@ -1,7 +1,7 @@
> /** @file
>Pei Core Main Entry Point
>
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> This program and the accompanying materials are licensed and made
> available under the terms and conditions of the BSD License which
> accompanies this distribution. The full text of the license may be found at
> @@ -80,23 +80,55 @@ ShadowPeiCore (
>IN PEI_CORE_INSTANCE *PrivateData
>)
> {
> - EFI_PEI_FILE_HANDLE PeiCoreFileHandle;
> - EFI_PHYSICAL_ADDRESS EntryPoint;
> - EFI_STATUS Status;
> - UINT32 AuthenticationState;
> + EFI_PEI_FILE_HANDLE PeiCoreFileHandle;
> + EFI_PHYSICAL_ADDRESS EntryPoint;
> + EFI_STATUS Status;
> + UINT32 AuthenticationState;
> + UINTNIndex;
> + EFI_PEI_CORE_FV_LOCATION_PPI *PeiCoreFvLocationPpi;
>
>PeiCoreFileHandle = NULL;
>
>//
> - // Find the PEI Core in the BFV
> + // Find the PEI Core either from EFI_PEI_CORE_FV_LOCATION_PPI
> + indicated FV or BFV
>//
> - Status = PrivateData->Fv[0].FvPpi->FindFileByType (
> - PrivateData->Fv[0].FvPpi,
> - EFI_FV_FILETYPE_PEI_CORE,
> - PrivateData->Fv[0].FvHandle,
> -
> - );
> - ASSERT_EFI_ERROR (Status);
> + Status = PeiServicesLocatePpi (
> + ,
> + 0,
> + NULL,
> + (VOID **)
> + );
> + if (!EFI_ERROR (Status) && (PeiCoreFvLocationPpi->PeiCoreFvLocation !=
> NULL)) {
> +//
> +// If PeiCoreFvLocation present, the PEI Core should be found from
> indicated FV.
> +//
> +for (Index = 0; Index < PrivateData->FvCount; Index ++) {
> + if ((UINT32) PrivateData->Fv[Index].FvHandle != (UINT32)
> PeiCoreFvLocationPpi->PeiCoreFvLocation) {
> +continue;
> + }
> + Status = PrivateData->Fv[Index].FvPpi->FindFileByType (
> + PrivateData->Fv[Index].FvPpi,
> + EFI_FV_FILETYPE_PEI_CORE,
> +
> PrivateData->Fv[Index].FvHandle,
> +
> + );
> + if (!EFI_ERROR (Status)) {
> +break;
1. Is it valid that PEI_CORE cannot be found in the PeiCoreFvLocation?
If no, why not assert here?
> + }
> +}
> +ASSERT (Index < PrivateData->FvCount); } else {
> +//
> +// Find PEI Core from BFV
> +//
> +Status = PrivateData->Fv[0].FvPpi->FindFileByType (
> + PrivateData->Fv[0].FvPpi,
> + EFI_FV_FILETYPE_PEI_CORE,
> + PrivateData->Fv[0].FvHandle,
> +
> + );
> +ASSERT_EFI_ERROR (Status);
> + }
>
>//
>// Shadow PEI Core into me
Re: [edk2] [PATCH 1/3] MdePkg: Support EFI_PEI_CORE_FV_LOCATION_PPI
Chasel,
I don't think the below forward definition is needed.
typedef struct _EFI_PEI_CORE_FV_LOCATION_PPI EFI_PEI_CORE_FV_LOCATION_PPI;
It is needed when the PPI contains methods and the methods requires This pointer
as the first parameter.
> -Original Message-
> From: edk2-devel On Behalf Of Chasel,
> Chiu
> Sent: Tuesday, February 12, 2019 9:20 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming
>
> Subject: [edk2] [PATCH 1/3] MdePkg: Support
> EFI_PEI_CORE_FV_LOCATION_PPI
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524
>
> Add EFI_PEI_CORE_FV_LOCATION_PPI definition basing on PI spec 1.7,
> Section 6.3.9.
> This PPI can support the secnario that PEI Foundation not in BFV.
>
> Cc: Michael D Kinney
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu
> ---
> MdePkg/Include/Ppi/PeiCoreFvLocation.h | 53
> +
> MdePkg/MdePkg.dec | 11 +--
> 2 files changed, 62 insertions(+), 2 deletions(-)
>
> diff --git a/MdePkg/Include/Ppi/PeiCoreFvLocation.h
> b/MdePkg/Include/Ppi/PeiCoreFvLocation.h
> new file mode 100644
> index 00..c7bbbfb265
> --- /dev/null
> +++ b/MdePkg/Include/Ppi/PeiCoreFvLocation.h
> @@ -0,0 +1,53 @@
> +/** @file
> + Header file for Pei Core FV Location PPI.
> +
> + This PPI contains a pointer to the firmware volume which contains the PEI
> Foundation.
> + If the PEI Foundation does not reside in the BFV, then SEC must pass
> + this PPI as a part of the PPI list provided to the PEI Foundation
> + Entry Point, otherwise the PEI Foundation shall assume that it resides
> within the BFV.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved. This
> + program and the accompanying materials are licensed and made
> + available under the terms and conditions of the BSD License which
> + accompanies this distribution. The full text of the license may be
> + found at http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> + @par Revision Reference:
> + This PPI is defined in UEFI Platform Initialization Specification 1.7
> Volume 1:
> + Standards
> +
> +**/
> +
> +
> +#ifndef _EFI_PEI_CORE_FV_LOCATION_H_
> +#define _EFI_PEI_CORE_FV_LOCATION_H_
> +
> +///
> +/// Global ID for EFI_PEI_CORE_FV_LOCATION_PPI /// #define
> +EFI_PEI_CORE_FV_LOCATION_GUID \
> + { \
> +0x52888eae, 0x5b10, 0x47d0, {0xa8, 0x7f, 0xb8, 0x22, 0xab, 0xa0,
> +0xca, 0xf4 } \
> + }
> +
> +///
> +/// Forward declaration for EFI_PEI_CORE_FV_LOCATION_PPI /// typedef
> +struct _EFI_PEI_CORE_FV_LOCATION_PPI
> EFI_PEI_CORE_FV_LOCATION_PPI;
> +
> +///
> +/// This PPI provides location of EFI PeiCoreFv.
> +///
> +struct _EFI_PEI_CORE_FV_LOCATION_PPI {
> + ///
> + /// Pointer to the first byte of the firmware volume which contains the PEI
> Foundation.
> + ///
> + VOID*PeiCoreFvLocation;
> +};
> +
> +extern EFI_GUID gEfiPeiCoreFvLocationPpiGuid;
> +
> +#endif // _EFI_PEI_CORE_FV_LOCATION_H_
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec index
> a485408310..c859b4a511 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -2,9 +2,9 @@
> # This Package provides all definitions, library classes and libraries
> instances.
> #
> # It also provides the definitions(including PPIs/PROTOCOLs/GUIDs) of -#
> EFI1.10/UEFI2.7/PI1.6 and some Industry Standards.
> +# EFI1.10/UEFI2.7/PI1.7 and some Industry Standards.
> #
> -# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2007 - 2019, Intel Corporation. All rights
> +reserved.
> # Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved. #
> (C)
> Copyright 2016 Hewlett Packard Enterprise Development LP # @@ -
> 929,6 +929,13 @@
>## Include/Ppi/SecHobData.h
>gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4, 0xee, 0xf5,
> 0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
>
> + #
> + # PPIs defined in PI 1.7.
> + #
> +
> + ## Include/Ppi/PeiCoreFvLocation.h
> + gEfiPeiCoreFvLocationPpiGuid = { 0x52888eae, 0x5b10, 0x47d0, { 0xa8,
> 0x7f, 0xb8, 0x22, 0xab, 0xa0, 0xca, 0xf4 }}
> +
> [Protocols]
>## Include/Protocol/Pcd.h
>gPcdProtocolGuid = { 0x11B34006, 0xD85B, 0x4D0A, { 0xA2,
> 0x90,
> 0xD5, 0xA5, 0x71, 0x31, 0x0E, 0xF7 }}
> --
> 2.13.3.windows.1
>
> ___
> 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
Re: [edk2] [PATCH v4 12/13] OvmfPkg/LockBoxLib: Update the comments for API UpdateLockBox()
Reviewed-by: Ray Ni -- Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 04/13] MdeModulePkg: Add GUID for LockBox to save storage dev to init in S3
Reviewed-by: Ray Ni -- Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 02/13] MdeModulePkg: Add definitions for EDKII PEI ATA PassThru PPI
On 2/11/2019 3:57 PM, Hao Wu wrote: REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409 This commit will add the definitions for EDKII PEI ATA PassThru PPI. This PPI will provide services that allow ATA commands to be sent to ATA devices attached to an ATA controller in the PEI phase. More specifically, the PPI will provide services to: * Send ATA commands to an ATA device (by service 'PassThru'); * Get the list of the attached ATA device on a controller (by services 'GetNextPort' and 'GetNextDevice'); * Get the identification information (DevicePath) of the underlying ATA host controller (by service 'GetDevicePath'). Cc: Jian J Wang Cc: Ruiyu Ni Cc: Eric Dong Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu Reviewed-by: Ray Ni -- Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Report StatusCode for device init failure
On 2/11/2019 3:57 PM, Hao Wu wrote: From: Sean Brogan REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1408 According to the information of the above BZ-1408 and other platform owners, NVM Express devices are becoming more likely to be a critical part during the boot process. This commit will add the calls to 'REPORT_STATUS_CODE' when there is a failure happens during the NVM Express controller/device initialization process. Cc: Sean Brogan Cc: Bret Barkelew Cc: Jian J Wang Cc: Ray Ni Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu Reviewed-by: Ray Ni -- Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 11/12] MdeModulePkg/SmmLockBoxLib: Support LockBox enlarge in UpdateLockBox()
Reviewed-by: Ray Ni -- Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API CalculateCrc16()
There is an CRC16 calculation implementation in
SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.c
Does your implementation generate the same CRC16 as above one?
> -Original Message-
> From: edk2-devel On Behalf Of Ming
> Huang
> Sent: Friday, February 1, 2019 2:02 PM
> To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Kinney, Michael D
> ; Gao, Liming
> Cc: huangmin...@huawei.com; Dong, Eric ;
> zhangjinso...@huawei.com; Zeng, Star ;
> wai...@126.com; wanghuiqi...@huawei.com; huangda...@hisilicon.com
> Subject: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API
> CalculateCrc16()
>
> CalculateCrc16() bases on the initialized mCrcTable. When CalculateCrc16() is
> used, mCrcTable16 will take 512Bytes size in the image. When
> CalculateCrc16() is not used, mCrcTable16 will not be built in the image, and
> no size impact.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang
> ---
> MdePkg/Include/Library/BaseLib.h | 20 ++
> MdePkg/Library/BaseLib/CheckSum.c | 73
> 2 files changed, 93 insertions(+)
>
> diff --git a/MdePkg/Include/Library/BaseLib.h
> b/MdePkg/Include/Library/BaseLib.h
> index 1eb842384ee2..956b971e5c69 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -4855,6 +4855,26 @@ CalculateCrc32(
>IN UINTNLength
>);
>
> +/**
> + Computes and returns a 16-bit CRC for a data buffer.
> + CRC16 value bases on CCITT.
> +
> + If Buffer is NULL, then ASSERT().
> + If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
> +
> + @param[in] Buffer A pointer to the buffer on which the 16-bit CRC
> is to
> be computed.
> + @param[in] Length The number of bytes in the buffer Data.
> +
> + @retval Crc16The 16-bit CRC was computed for the data buffer.
> +
> +**/
> +UINT16
> +EFIAPI
> +CalculateCrc16(
> + IN VOID *Buffer,
> + IN UINTNLength
> + );
> +
> //
> // Base Library CPU Functions
> //
> diff --git a/MdePkg/Library/BaseLib/CheckSum.c
> b/MdePkg/Library/BaseLib/CheckSum.c
> index 03d49afc5e6c..4e27aebe44bc 100644
> --- a/MdePkg/Library/BaseLib/CheckSum.c
> +++ b/MdePkg/Library/BaseLib/CheckSum.c
> @@ -630,3 +630,76 @@ CalculateCrc32(
>
>return Crc ^ 0x;
> }
> +
> +GLOBAL_REMOVE_IF_UNREFERENCED CONST UINT16 mCrcTable16[256] =
> {
> + 0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
> + 0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,
> + 0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,
> + 0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,
> + 0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,
> + 0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,
> + 0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,
> + 0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,
> + 0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,
> + 0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B,
> + 0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,
> + 0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A,
> + 0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,
> + 0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49,
> + 0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,
> + 0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78,
> + 0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F,
> + 0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,
> + 0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E,
> + 0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256,
> + 0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D,
> + 0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
> + 0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C,
> + 0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,
> + 0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB,
> + 0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,
> + 0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,
> + 0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,
> + 0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,
> + 0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,
> + 0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8,
> + 0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0 };
> +
> +/**
> + Computes and returns a 16-bit CRC for a data buffer.
> + CRC16 value bases on CCITT.
> +
> + If Buffer is NULL, then ASSERT().
> + If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
> +
> + @param[in] Buffer A pointer to the buffer on which the 16-bit CRC
> is to
> be
Re: [edk2] [PATCH 5/5] IntelSiliconPkg\Include\IndustryStandard: Update IGD_OPREGION_MBOX3 Structure
Reviewed-by: Ray Ni
> -Original Message-
> From: Solanki, Digant H
> Sent: Thursday, January 31, 2019 4:01 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray ; Gao, Liming ;
> Chaganty, Rangasai V
> Subject: [PATCH 5/5] IntelSiliconPkg\Include\IndustryStandard: Update
> IGD_OPREGION_MBOX3 Structure
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1454
> Based on latest IGD OpRegion Spec, IGD_OPREGION_MBOX3 needs to be
> updated with two new members : Physical Address of Raw VBT Data (RVDA)
> and Size of Raw VBT Data (RVDS)
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Digant H Solanki
> Cc: Ray Ni
> Cc: Liming Gao
> Cc: Rangasai V Chaganty
> ---
> IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
> b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
> index 5ce80a5be8..300a85a717 100644
> --- a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
> +++ b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
> @@ -4,9 +4,7 @@
>
>https://01.org/sites/default/files/documentation/skl_opregion_rev0p5.pdf
>
> - @note Fixed bug in the spec Mailbox3 - RM31 size from 0x45(69) to 0x46(70)
> -
> - Copyright (c) 2016, Intel Corporation. All rights reserved.
> + Copyright (c) 2016 - 2019, Intel Corporation. All rights
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution. The full text of the license may be
> found at @@ -118,7 +116,9 @@ typedef struct {
>UINT64 FDSS; ///< Offset 0x3AA DSS Buffer address allocated for
> IFFS
> feature
>UINT32 FDSP; ///< Offset 0x3B2 Size of DSS buffer
>UINT32 STAT; ///< Offset 0x3B6 State Indicator
> - UINT8 RM31[0x46];///< Offset 0x3BA - 0x3FF Reserved Must be zero.
> Bug in spec 0x45(69)
> + UINT64 RVDA; ///< Offset 0x3BA Physical address of Raw VBT data.
> Added from Spec Version 0.90 to support VBT greater than 6KB.
> + UINT32 RVDS; ///< Offset 0x3C2 Size of Raw VBT data. Added from
> Spec Version 0.90 to support VBT greater than 6KB.
> + UINT8 RM32[0x3A];///< Offset 0x3C6 - 0x3FF Reserved Must be zero.
> } IGD_OPREGION_MBOX3;
>
> ///
> --
> 2.18.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] Proposal to split Pkgs
On 1/31/2019 3:51 PM, Ard Biesheuvel wrote: The POC code is inhttps://github.com/jyao1/edk2/tree/ReOrg. It basically split the EDKII common code to three directories: Core/, Device/, and Feature/. I'm not sure I like the 'Device' name, but that's not that important at this stage - I like that this is split up the way it is. I also think a lot of things currently under Feture/misc could be broken out into additional subdirectories under Feature/. The code is in very early POC phase and only code in Core/ directory can pass the build. I would like to gather feedbacks through this RFC to see whether this splitting direction makes sense. Is there any other better ways of splitting? Or perhaps do not split in such a small granularity? I think this would be my only negative(ish) feedback on the POC. While it has the benefit of modules requiring to specify more precisely which functionality they are pulling in... ...it means that they now need to list*everything*. And with the mechanism by which I have seen Intel engineers make use of PACKAGES_PATH in the past*, we end up with a bazillion packages that need to be added individually to this variable for each build. No. "PACKAGES_PATH" only contains paths pointing to the*parent* directory of *Pkg. In this case, it equals to: /work/edk2/Core:/work/edk2/Device:/work/edk2/Feature/security:/work/edk2/Feature/network:/work/edk2/Feature/misc Could we*please* not do this? PACKAGES_PATH is very useful for combining packages from different repositories, but that does not mean we should split up the core repository in this way. What we will end up with is platforms that use Core/Package/Foo.inf and platforms that use Package/Foo.inf which creates an aliasing mess where the same file is reachable in different ways. Also, it encourages the behavior where you need to fetch version X of repo A and version Y of repo B, and the whole point of open sourcing is to have all code co-exist in the same source tree. Ard, Some platforms which define PACKAGES_PATH to "/work/edk2" will have "Core/Package/Foo.inf" in the DSC/FDF. Some platforms which define PACKAGES_PATH to "/work/edk2/Core" will have "Package/Foo.inf" in the DSC/FDF. It's bad and I 100% agree! The basic rule behind that is PACKAGES_PATH should only contains path pointing to the root of repo. Thanks for raising a very good concern on putting packages inside sub-directory. -- Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v5] MdePkg/BaseLib: Add Base64Encode() and Base64Decode()
Even ECC doesn't complain, I still suggest to change Encoding_table/Decoding_table to a proper name, e.g.: EncodingTable/DecodingTable. With the rename applied in V5 patch, Reviewed-by: Ray Ni ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] IntelSiliconPkg\Include\IndustryStandard: Update IGD_OPREGION_MBOX3 Structure
On 1/31/2019 2:55 PM, Ni, Ray wrote:
On 1/31/2019 1:00 PM, Digant H Solanki wrote:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1454
Based on latest IGD OpRegion Spec, IGD_OPREGION_MBOX3 needs to be
updated with two new members : Physical Address of Raw VBT Data (RVDA)
and Size of Raw VBT Data (RVDS)
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Digant H Solanki
Cc: Liming Gao
Cc: Chaganty, Rangasai V
Cc: Ni, Ray
---
IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
index 5ce80a5be8..1c83efee40 100644
--- a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
+++ b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
@@ -4,9 +4,7 @@
https://01.org/sites/default/files/documentation/skl_opregion_rev0p5.pdf
- @note Fixed bug in the spec Mailbox3 - RM31 size from 0x45(69) to
0x46(70)
-
- Copyright (c) 2016, Intel Corporation. All rights reserved.
+ Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.
This program and the accompanying materials
are licensed and made available under the terms and conditions of
the BSD License
which accompanies this distribution. The full text of the license
may be found at
@@ -118,7 +116,9 @@ typedef struct {
UINT64 FDSS; ///< Offset 0x3AA DSS Buffer address
allocated for IFFS feature
UINT32 FDSP; ///< Offset 0x3B2 Size of DSS buffer
UINT32 STAT; ///< Offset 0x3B6 State Indicator
- UINT8 RM31[0x46]; ///< Offset 0x3BA - 0x3FF Reserved Must be
zero. Bug in spec 0x45(69)
+ UINT64 RVDA; ///< Offset 0x3BA Physical address of Raw VBT
data. Added from Spec Version 0.90 to support VBT greater than 6KB.
+ UINT32 RVDS; ///< Offset 0x3C2 Size of Raw VBT data. Added
from Spec Version 0.90 to support VBT greater than 6KB.
+ UINT8 RM31[0x3A]; ///< Offset 0x3C6 - 0x3FF Reserved Must be
zero.
} IGD_OPREGION_MBOX3;
///
Sorry seems my comment was missed in previous mail.
Is it possible that an existing consumer is already using
RM31 to access RVDA and RVDS? For example,
using " * (UINT64 *) RM31[0]" to access RVDA.
If it's possible, I suggest we rename "RM31" to a different name.
Otherwise, the original code that modifies RVDA using RM may
incorrectly modifies bytes at offset 0x3C6.
A build failure instead of a silent failure can be seen with the rename.
--
Thanks,
Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] Proposal to split Pkgs
On 1/29/2019 10:21 PM, Leif Lindholm wrote: Hi Ray, First of all, thank you for restarting this discussion, and putting the effort in for a POC. On Tue, Jan 29, 2019 at 05:59:35AM +, Ni, Ray wrote: Hello, I'd like to propose to split today's BIG packages in following ways: ==Overview = 1. Separate Industry standard definitions from UEFI and PI interfaces. 2. Separate UEFI and PI interfaces from implementations. a. Separate UEFI and PI interfaces to different packages b. Separate PI PEI, DXE and MM phase interfaces to different packages 3. Separate different features into feature packages. Feature interface may be in the feature package to provide minimal common interface packages. The POC code is in https://github.com/jyao1/edk2/tree/ReOrg. It basically split the EDKII common code to three directories: Core/, Device/, and Feature/. I'm not sure I like the 'Device' name, but that's not that important at this stage - I like that this is split up the way it is. I also think a lot of things currently under Feture/misc could be broken out into additional subdirectories under Feature/. The code is in very early POC phase and only code in Core/ directory can pass the build. I would like to gather feedbacks through this RFC to see whether this splitting direction makes sense. Is there any other better ways of splitting? Or perhaps do not split in such a small granularity? I think this would be my only negative(ish) feedback on the POC. While it has the benefit of modules requiring to specify more precisely which functionality they are pulling in... ...it means that they now need to list *everything*. And with the mechanism by which I have seen Intel engineers make use of PACKAGES_PATH in the past*, we end up with a bazillion packages that need to be added individually to this variable for each build. No. "PACKAGES_PATH" only contains paths pointing to the *parent* directory of *Pkg. In this case, it equals to: /work/edk2/Core:/work/edk2/Device:/work/edk2/Feature/security:/work/edk2/Feature/network:/work/edk2/Feature/misc * (arguably how it was designed to be used - just not how I am interested in using it) It also means that we need *tons* of dummy .dsc files in order to run through simple build tests. Yes each small package needs its own DSC and DEC. DSC to list all components. DEC to list all interfaces. OK maybe the "need" in your wording means the build test script file needs to reference all DSC files. That maybe can be solved by an advanced script to call "build" for each DSC files inside a directory that matches a specific pattern. So the build test script to build PiPeiPkg/PiDxePkg/PiMmPkg will be like: build-any-dsc /work/edk2/Core/ --pattern="*Pi*" My preference would be to push the packages back up to the top-level. The split still makes sense, and allocating maintainers to sub-parts can happen without a full-out redesign of the Maintainers.txt format. (Which I will try to resurrect with a proposal over the next few weeks anyway.) Combining all packages inside the Device and Feature directory to still one single big package but with another directory layout so that only single DSC/DEC is needed? Or perhaps Mike's work to move lib-c content to edk2-libc repo, to move real platform code to edk2-platform repo is enough for now? I think we need this further restructuring, and renaming. Not just for splitting up maintainership duties (which as I mentioned in email to Laszlo, we will still need to do with this change). But to make the codebase more approachable. "more approachable" means more friendly to new comers? Just try to understand everyone's real concern to today's codebase. ==More explanations = There are 9 packages inside Core/ directory: 1. BasePkg Contains industry standard definitions (exclude UEFI and PI) and base libraries that non-UEFI and non-PI development can depend on. UEFI or PI development can also depend on this package. 2. UefiPkg Contains UEFI interfaces and libraries that UEFI driver-model driver development can depend on. 3. PiPeiPkg Contains PI interfaces and libraries for PEI phase that PEI module development can depend on. 4. PiDxePkg Contains PI interfaces and libraries for DXE phase that DXE module development can depend on. Really happy with the above split. 5. PiMmPkg Contains PI interfaces and libraries for MM phase that MM/SMM module development can depend on. How would/should this work relative to StandaloneMmPkg? The "Mm" is to reflect to the same word in PI spec. But I didn't check whether "StandaloneMmPkg" can work with the this. 6. MdeModulePkg (TianoPkg? Name is still TBD) Yes, this needs to be renamed. I don't object to the Tiano naming. Thanks. Contains Tiano implementation specific interfaces and libraries. Developing modules for
Re: [edk2] [PATCH 2/2] IntelSiliconPkg\Include\IndustryStandard: Update IGD_OPREGION_MBOX3 Structure
On 1/31/2019 1:00 PM, Digant H Solanki wrote:
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1454
Based on latest IGD OpRegion Spec, IGD_OPREGION_MBOX3 needs to be updated with
two new members : Physical Address of Raw VBT Data (RVDA) and Size of Raw VBT
Data (RVDS)
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Digant H Solanki
Cc: Liming Gao
Cc: Chaganty, Rangasai V
Cc: Ni, Ray
---
IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
index 5ce80a5be8..1c83efee40 100644
--- a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
+++ b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
@@ -4,9 +4,7 @@
https://01.org/sites/default/files/documentation/skl_opregion_rev0p5.pdf
- @note Fixed bug in the spec Mailbox3 - RM31 size from 0x45(69) to 0x46(70)
-
- Copyright (c) 2016, Intel Corporation. All rights reserved.
+ Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
which accompanies this distribution. The full text of the license may be
found at
@@ -118,7 +116,9 @@ typedef struct {
UINT64 FDSS; ///< Offset 0x3AA DSS Buffer address allocated for
IFFS feature
UINT32 FDSP; ///< Offset 0x3B2 Size of DSS buffer
UINT32 STAT; ///< Offset 0x3B6 State Indicator
- UINT8 RM31[0x46];///< Offset 0x3BA - 0x3FF Reserved Must be zero. Bug
in spec 0x45(69)
+ UINT64 RVDA; ///< Offset 0x3BA Physical address of Raw VBT data.
Added from Spec Version 0.90 to support VBT greater than 6KB.
+ UINT32 RVDS; ///< Offset 0x3C2 Size of Raw VBT data. Added from
Spec Version 0.90 to support VBT greater than 6KB.
+ UINT8 RM31[0x3A];///< Offset 0x3C6 - 0x3FF Reserved Must be zero.
} IGD_OPREGION_MBOX3;
///
--
Thanks,
Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 07/12] MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, January 31, 2019 10:49 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Wang, Jian J ;
> Ni, Ray ; Dong, Eric
> Subject: [PATCH v2 07/12] MdeModulePkg/NvmExpressPei: Consume
> S3StorageDeviceInitList LockBox
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409
>
> For the NvmExpressPei driver, this commit will update the driver to consume
> the S3StorageDeviceInitList LockBox in S3 phase. The purpose is to perform
> an on-demand (partial) NVM Express device enumeration/initialization to
> benefit the S3 resume performance.
>
> Cc: Jian J Wang
> Cc: Ray Ni
> Cc: Eric Dong
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf | 8 +-
> MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h | 16 +++
> MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c | 20
> MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiS3.c | 106
>
> 4 files changed, 149 insertions(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
> b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
> index 0666e5892b..22b703e971 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
> @@ -40,6 +40,7 @@
>NvmExpressPeiHci.h
>NvmExpressPeiPassThru.c
>NvmExpressPeiPassThru.h
> + NvmExpressPeiS3.c
>NvmExpressPeiStorageSecurity.c
>NvmExpressPeiStorageSecurity.h
>
> @@ -54,6 +55,7 @@
>BaseMemoryLib
>IoLib
>TimerLib
> + LockBoxLib
>PeimEntryPoint
>
> [Ppis]
> @@ -64,9 +66,13 @@
>gEfiPeiVirtualBlockIo2PpiGuid ## SOMETIMES_PRODUCES
>gEdkiiPeiStorageSecurityCommandPpiGuid ## SOMETIMES_PRODUCES
>
> +[Guids]
> + gS3StorageDeviceInitListGuid ## SOMETIMES_CONSUMES ##
> UNDEFINED
> +
> [Depex]
>gEfiPeiMemoryDiscoveredPpiGuid AND
> - gEdkiiPeiNvmExpressHostControllerPpiGuid
> + gEdkiiPeiNvmExpressHostControllerPpiGuid AND
> + gEfiPeiMasterBootModePpiGuid
>
> [UserExtensions.TianoCore."ExtraFiles"]
>NvmExpressPeiExtra.uni
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> index 7047c4f3ff..6f01413e6d 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> @@ -332,4 +332,20 @@ NvmeBuildDevicePath (
>OUT EFI_DEVICE_PATH_PROTOCOL**DevicePath
>);
>
> +/**
> + Determine if a specific NVM Express controller can be skipped for S3 phase.
> +
> + @param[in] HcDevicePath Device path of the controller.
> + @param[in] HcDevicePathLengthLength of the device path specified by
> +HcDevicePath.
> +
> + @retvalThe number of ports that need to be enumerated.
> +
> +**/
> +BOOLEAN
> +NvmeS3SkipThisController (
> + IN EFI_DEVICE_PATH_PROTOCOL*HcDevicePath,
> + IN UINTN HcDevicePathLength
> + );
> +
> #endif
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c
> b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c
> index 96622e6fd5..43b2dfc3e7 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c
> @@ -213,6 +213,7 @@ NvmExpressPeimEntry (
>)
> {
>EFI_STATUS Status;
> + EFI_BOOT_MODEBootMode;
>EDKII_NVM_EXPRESS_HOST_CONTROLLER_PPI*NvmeHcPpi;
>UINT8Controller;
>UINTNMmioBase;
> @@ -224,6 +225,15 @@ NvmExpressPeimEntry (
>DEBUG ((DEBUG_INFO, "%a: Enters.\n", __FUNCTION__));
>
>//
> + // Get the current boot mode.
> + //
> + Status = PeiServicesGetBootMode (); if (EFI_ERROR (Status))
> + {
> +DEBUG ((DEBUG_ERROR, "%a: Fail to get the current boot mode.\n",
> __FUNCTION__));
> +return Status;
> + }
> +
> + //
>// Locate the NVME host controller PPI
>//
>Status = PeiServicesLocatePpi (
> @@ -279,6 +289,16 @@ NvmExpressPeimEntry (
>continue;
> }
>
> +if ((BootMode == BOOT_ON_S3_RESUME) &&
> +(NvmeS3SkipThisController (DevicePath, DevicePathLength))) {
> + DEBUG ((
> +DEBUG_ERROR, "%a: Controller %d is skipped during S3.\n",
> +__FUNCTION__, Controller
> +));
>
Re: [edk2] [PATCH v2 06/12] MdeModulePkg/NvmExpressPei: Add logic to produce SSC PPI
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, January 31, 2019 10:49 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Wang, Jian J ;
> Ni, Ray ; Dong, Eric
> Subject: [PATCH v2 06/12] MdeModulePkg/NvmExpressPei: Add logic to
> produce SSC PPI
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409
>
> For the NvmExpressPei driver, this commit will add codes to produce the
> Storage Security Command PPI if the underlying NVM Express controller
> supports the Security Send and Security Receive commands.
>
> Cc: Jian J Wang
> Cc: Ray Ni
> Cc: Eric Dong
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf | 10 +-
> MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h| 81
> +++-
> MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.h | 20 +-
> MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.h
> | 247
> MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c | 317
> +++
> MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c| 143
> +--
> MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.c | 32 +-
> MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.c
> | 423
> 8 files changed, 1184 insertions(+), 89 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
> b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
> index 9591572fec..0666e5892b 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
> @@ -2,7 +2,7 @@
> # The NvmExpressPei driver is used to manage non-volatile memory
> subsystem
> # which follows NVM Express specification at PEI phase.
> #
> -# Copyright (c) 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2018 - 2019, Intel Corporation. All rights reserved.
> #
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the
> BSD License
> @@ -30,6 +30,7 @@
> #
>
> [Sources]
> + DevicePath.c
>DmaMem.c
>NvmExpressPei.c
>NvmExpressPei.h
> @@ -39,6 +40,8 @@
>NvmExpressPeiHci.h
>NvmExpressPeiPassThru.c
>NvmExpressPeiPassThru.h
> + NvmExpressPeiStorageSecurity.c
> + NvmExpressPeiStorageSecurity.h
>
> [Packages]
>MdePkg/MdePkg.dec
> @@ -54,11 +57,12 @@
>PeimEntryPoint
>
> [Ppis]
> - gEfiPeiVirtualBlockIoPpiGuid ## PRODUCES
> - gEfiPeiVirtualBlockIo2PpiGuid ## PRODUCES
>gEdkiiPeiNvmExpressHostControllerPpiGuid ## CONSUMES
>gEdkiiIoMmuPpiGuid ## CONSUMES
>gEfiEndOfPeiSignalPpiGuid ## CONSUMES
> + gEfiPeiVirtualBlockIoPpiGuid ## SOMETIMES_PRODUCES
> + gEfiPeiVirtualBlockIo2PpiGuid ## SOMETIMES_PRODUCES
> + gEdkiiPeiStorageSecurityCommandPpiGuid ##
> SOMETIMES_PRODUCES
>
> [Depex]
>gEfiPeiMemoryDiscoveredPpiGuid AND
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> index 0135eca6f0..7047c4f3ff 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> @@ -25,6 +25,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -44,6 +45,7 @@ typedef struct
> _PEI_NVME_CONTROLLER_PRIVATE_DATA
> PEI_NVME_CONTROLLER_PRIVATE_DA
> #include "NvmExpressPeiHci.h"
> #include "NvmExpressPeiPassThru.h"
> #include "NvmExpressPeiBlockIo.h"
> +#include "NvmExpressPeiStorageSecurity.h"
>
> //
> // NVME PEI driver implementation related definitions
> @@ -90,10 +92,15 @@ struct _PEI_NVME_NAMESPACE_INFO {
> struct _PEI_NVME_CONTROLLER_PRIVATE_DATA {
>UINT32Signature;
>UINTN MmioBase;
> + UINTN DevicePathLength;
> + EFI_DEVICE_PATH_PROTOCOL *DevicePath;
> +
>EFI_PEI_RECOVERY_BLOCK_IO_PPI BlkIoPpi;
>EFI_PEI_RECOVERY_BLOCK_IO2_PPIBlkIo2Ppi;
> + EDKII_PEI_STORAGE_SECURITY_CMD_PPIStorageSecurityPpi;
>EFI_PEI_PPI_DESCRIPTORBlkIoPpiList;
>EFI_PEI_PPI_DESCRIPTORBlkIo2PpiList;
> + EFI_PEI_PPI_DESCRIPTORStorageSecurityPpiList
Re: [edk2] [PATCH v2 05/12] MdeModulePkg/NvmExpressPei: Avoid updating the module-level variable
Reviewed-by: Ray Ni
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, January 31, 2019 10:49 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Wang, Jian J ;
> Ni, Ray
> Subject: [PATCH v2 05/12] MdeModulePkg/NvmExpressPei: Avoid updating
> the module-level variable
>
> This commit is out of the scope for BZ-1409. The commit will remove the call
> of RegisterForShadow() at the entry point of the driver. By doing so, the
> driver is now possible to be executed without being re-loaded into
> permanent memory.
>
> Thus, this commit will update the NvmExpressPei driver to avoid updating
> the content of a global variable.
>
> Cc: Jian J Wang
> Cc: Ray Ni
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h | 12 +-
> MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c| 153
> +++-
> MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c | 11 +-
> 3 files changed, 92 insertions(+), 84 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> index 0bd62c2459..0135eca6f0 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
> @@ -2,7 +2,7 @@
>The NvmExpressPei driver is used to manage non-volatile memory
> subsystem
>which follows NVM Express specification at PEI phase.
>
> - Copyright (c) 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2018 - 2019, Intel Corporation. All rights
> + reserved.
>
>This program and the accompanying materials
>are licensed and made available under the terms and conditions @@ -
> 147,13 +147,9 @@ struct _PEI_NVME_CONTROLLER_PRIVATE_DATA {
>CR (a, PEI_NVME_CONTROLLER_PRIVATE_DATA, EndOfPeiNotifyList,
> NVME_PEI_CONTROLLER_PRIVATE_DATA_SIGNATURE)
>
>
> -/**
> - Initialize IOMMU.
> -**/
> -VOID
> -IoMmuInit (
> - VOID
> - );
> +//
> +// Internal functions
> +//
>
> /**
>Allocates pages that are suitable for an OperationBusMasterCommonBuffer
> or diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c
> b/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c
> index 51b48d38dd..cb629c16b0 100644
> --- a/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c
> +++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c
> @@ -1,7 +1,7 @@
> /** @file
>The DMA memory help function.
>
> - Copyright (c) 2018, Intel Corporation. All rights reserved.
> + Copyright (c) 2018 - 2019, Intel Corporation. All rights
> + reserved.
>
>This program and the accompanying materials
>are licensed and made available under the terms and conditions @@ -16,7
> +16,33 @@
>
> #include "NvmExpressPei.h"
>
> -EDKII_IOMMU_PPI *mIoMmu;
> +/**
> + Get IOMMU PPI.
> +
> + @return Pointer to IOMMU PPI.
> +
> +**/
> +EDKII_IOMMU_PPI *
> +GetIoMmu (
> + VOID
> + )
> +{
> + EFI_STATUS Status;
> + EDKII_IOMMU_PPI*IoMmu;
> +
> + IoMmu = NULL;
> + Status = PeiServicesLocatePpi (
> + ,
> + 0,
> + NULL,
> + (VOID **)
> + );
> + if (!EFI_ERROR (Status) && (IoMmu != NULL)) {
> +return IoMmu;
> + }
> +
> + return NULL;
> +}
>
> /**
>Provides the controller-specific addresses required to access system
> memory from a @@ -46,18 +72,21 @@ IoMmuMap (
>OUT VOID **Mapping
>)
> {
> - EFI_STATUS Status;
> - UINT64 Attribute;
> -
> - if (mIoMmu != NULL) {
> -Status = mIoMmu->Map (
> - mIoMmu,
> - Operation,
> - HostAddress,
> - NumberOfBytes,
> - DeviceAddress,
> - Mapping
> - );
> + EFI_STATUS Status;
> + UINT64 Attribute;
> + EDKII_IOMMU_PPI*IoMmu;
> +
> + IoMmu = GetIoMmu ();
> +
> + if (IoMmu != NULL) {
> +Status = IoMmu->Map (
> + IoMmu,
> + Operation,
> + HostAddress,
> + NumberOfBytes,
> + DeviceAddress,
> + Mapping
> + );
> if (EFI_ERROR (Status)) {
>return EFI_OUT_OF_RESOURCES;
> }
> @@ -78,11 +107,11 @@ IoMmuMap (
>ASSERT(FALSE);
>return EFI_INVALID_PARAMETER;
> }
> -Status = mIoMmu->SetAttribute (
> - mIo
Re: [edk2] [PATCH v2 03/12] MdeModulePkg: Add definitions for Storage Security Command PPI
Reviewed-by: Ray Ni
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, January 31, 2019 10:49 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Wang, Jian J ;
> Ni, Ray ; Dong, Eric
> Subject: [PATCH v2 03/12] MdeModulePkg: Add definitions for Storage
> Security Command PPI
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409
>
> This commit will add the definitions for Storage Security Command (SSC) PPI.
> This PPI will be be used to abstract mass storage devices to allow code
> running in the PEI phase to send security protocol commands to mass storage
> devices without specific knowledge of the type of device or controller that
> manages the device.
>
> More specifically, the PPI will provide services to:
>
> * Get the number of mass storage devices managed by a instance of the SSC
> PPI (by service 'GetNumberofDevices');
> * Get the identification information (DevicePath) of a managing mass
> storage devices (by service 'GetDevicePath');
> * Send security protocol commands to mass storage devices (by services
> 'ReceiveData' and 'SendData').
>
> Cc: Jian J Wang
> Cc: Ray Ni
> Cc: Eric Dong
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/MdeModulePkg.dec | 3 +
> MdeModulePkg/Include/Ppi/StorageSecurityCommand.h | 283
>
> 2 files changed, 286 insertions(+)
>
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec index 8efb19e626..7f646d7702
> 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -483,6 +483,9 @@
>## Include/Ppi/AtaAhciController.h
>gEdkiiPeiAtaAhciHostControllerPpiGuid = { 0x61dd33ea, 0x421f, 0x4cc0,
> { 0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 0x61 } }
>
> + ## Include/Ppi/StorageSecurityCommand.h
> + gEdkiiPeiStorageSecurityCommandPpiGuid= { 0x35de0b4e, 0x30fb,
> 0x46c3, { 0xbd, 0x84, 0x1f, 0xdb, 0xa1, 0x58, 0xbb, 0x56 } }
> +
>## Include/Ppi/AtaPassThru.h
>gEdkiiPeiAtaPassThruPpiGuid = { 0xa16473fd, 0xd474, 0x4c89,
> { 0xae,
> 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 0x9 } }
>
> diff --git a/MdeModulePkg/Include/Ppi/StorageSecurityCommand.h
> b/MdeModulePkg/Include/Ppi/StorageSecurityCommand.h
> new file mode 100644
> index 00..cc1688dabb
> --- /dev/null
> +++ b/MdeModulePkg/Include/Ppi/StorageSecurityCommand.h
> @@ -0,0 +1,283 @@
> +/** @file
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved. This
> + program and the accompanying materials are licensed and made
> + available under the terms and conditions of the BSD License which
> + accompanies this distribution. The full text of the license may be
> + found at http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef _EDKII_STORAGE_SECURITY_COMMAND_PPI_H_
> +#define _EDKII_STORAGE_SECURITY_COMMAND_PPI_H_
> +
> +#include
> +
> +///
> +/// Global ID for the EDKII_PEI_STORAGE_SECURITY_CMD_PPI.
> +///
> +#define EDKII_PEI_STORAGE_SECURITY_CMD_PPI_GUID \
> + { \
> +0x35de0b4e, 0x30fb, 0x46c3, { 0xbd, 0x84, 0x1f, 0xdb, 0xa1, 0x58,
> +0xbb, 0x56 } \
> + }
> +
> +//
> +// Forward declaration for the EDKII_PEI_STORAGE_SECURITY_CMD_PPI.
> +//
> +typedef struct _EDKII_PEI_STORAGE_SECURITY_CMD_PPI
> +EDKII_PEI_STORAGE_SECURITY_CMD_PPI;
> +
> +//
> +// Revision The revision to which the Storage Security Command interface
> adheres.
> +// All future revisions must be backwards compatible.
> +// If a future version is not back wards compatible it is not the
> same
> GUID.
> +//
> +#define EDKII_STORAGE_SECURITY_PPI_REVISION 0x0001
> +
> +
> +/**
> + Gets the count of storage security devices that one specific driver
> detects.
> +
> + @param[in] This The PPI instance pointer.
> + @param[out] NumberofDevicesThe number of storage security devices
> discovered.
> +
> + @retval EFI_SUCCESS The operation performed successfully.
> + @retval EFI_INVALID_PARAMETERThe parameters are invalid.
> +
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI *EDKII_PEI_STORAGE_SECURITY_GET_NUMBER_DEVICES) (
> + IN EDKII_PEI_STORAGE_SECURITY_CMD_PPI*This,
> + OUT UINTN *NumberofDevices
> + );
> +
> +/**
> + Gets the device path of a specific storage security device.
> +
> + @p
Re: [edk2] [PATCH v2 04/12] MdeModulePkg: Add GUID for LockBox to save storage dev to init in S3
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, January 31, 2019 10:49 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Wang, Jian J ;
> Ni, Ray ; Dong, Eric
> Subject: [PATCH v2 04/12] MdeModulePkg: Add GUID for LockBox to save
> storage dev to init in S3
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409
>
> This commit will add the GUID definitions for LockBox which is used to save a
> list of storage devices that need to get initialized during the S3 resume.
>
> The content of the LockBox will be a DevicePath structure that contains zero
> or more DevicePath instances. Each instance denotes a storage device that
> needs to get initialized during the S3 resume.
>
> The producers of the content of this LockBox will be drivers like
> OpalPassword DXE driver. This kind of drivers requires some specific storage
> devices to be initialized during the PEI phase of in S3 resume.
> (For the OpalPasword case, it requires the managing devices to be
> automatically unlocked during the S3 resume).
>
> The attribute of the LockBox should be set to
> LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY.
>
> The consumers of the content of this LockBox will be PEI storage device
> controller/bus drivers (e.g. NvmExpressPei) during S3 resume. This kind of
> drivers can use the DevicePath instances stored in the LockBox to get a list
> of
> devices that need to get initialized. In such way, an on-demand
> (partial) device enumeration/initialization can be performed to benefit the S3
> resume performance.
>
> Cc: Jian J Wang
> Cc: Ray Ni
> Cc: Eric Dong
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/MdeModulePkg.dec | 3 ++
> MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h | 36
>
> 2 files changed, 39 insertions(+)
>
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec index 7f646d7702..a2130bc439
> 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -422,6 +422,9 @@
>## Include/Guid/S3SmmInitDone.h
>gEdkiiS3SmmInitDoneGuid = { 0x8f9d4825, 0x797d, 0x48fc, { 0x84, 0x71,
> 0x84, 0x50, 0x25, 0x79, 0x2e, 0xf6 } }
>
> + ## Include/Guid/S3StorageDeviceInitList.h
> + gS3StorageDeviceInitListGuid = { 0x310e9b8c, 0xcf90, 0x421e, { 0x8e,
> + 0x9b, 0x9e, 0xef, 0xb6, 0x17, 0xc8, 0xef } }
> +
> [Ppis]
>## Include/Ppi/AtaController.h
>gPeiAtaControllerPpiGuid = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0,
> 0x7a,
> 0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
> diff --git a/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
> b/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
> new file mode 100644
> index 00..cfbd2a78e7
> --- /dev/null
> +++ b/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
> @@ -0,0 +1,36 @@
> +/** @file
> + Define the LockBox GUID for list of storage devices need to be
> +initialized in
> + S3.
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved.
> +
> + This program and the accompanying materials are licensed and made
> + available under the terms and conditions of the BSD License which
> + accompanies this distribution. The full text of the license may be
> + found at http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef __S3_STORAGE_DEVICE_INIT_LIST_H__ #define
> +__S3_STORAGE_DEVICE_INIT_LIST_H__
> +
> +#define S3_STORAGE_DEVICE_INIT_LIST \
> + { \
> +0x310e9b8c, 0xcf90, 0x421e, { 0x8e, 0x9b, 0x9e, 0xef, 0xb6, 0x17,
> +0xc8, 0xef } \
> + }
> +
> +//
> +// The LockBox will store a DevicePath structure that contains zero or
> +more // DevicePath instances. Each instance denotes a storage device
> +that needs to // get initialized during the S3 resume.
Can you have some pseudo code to describe the structure?
> +//
> +// The attribute of the LockBox should be set to //
> +'LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY'.
> +//
> +extern EFI_GUID gS3StorageDeviceInitListGuid;
> +
> +#endif // __S3_STORAGE_DEVICE_INIT_LIST_H__
> --
> 2.12.0.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 01/12] MdeModulePkg: Add definitions for ATA AHCI host controller PPI
Reviewed-by: Ray Ni
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, January 31, 2019 10:49 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Wang, Jian J ;
> Ni, Ray ; Dong, Eric
> Subject: [PATCH v2 01/12] MdeModulePkg: Add definitions for ATA AHCI
> host controller PPI
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409
>
> This commit will add the definitions for ATA AHCI host controller PPI. The
> purpose of the PPI in to provide:
>
> * MMIO base address
> * Controller identification information (DevicePath)
>
> for ATA host controllers working under AHCI mode.
>
> Cc: Jian J Wang
> Cc: Ray Ni
> Cc: Eric Dong
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/MdeModulePkg.dec| 3 +
> MdeModulePkg/Include/Ppi/AtaAhciController.h | 89
>
> 2 files changed, 92 insertions(+)
>
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec index e5c32d15ed..4411185073
> 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -480,6 +480,9 @@
>## Include/Ppi/NvmExpressHostController.h
>gEdkiiPeiNvmExpressHostControllerPpiGuid = { 0xcae3aa63, 0x676f, 0x4da3,
> { 0xbd, 0x50, 0x6c, 0xc5, 0xed, 0xde, 0x9a, 0xad } }
>
> + ## Include/Ppi/AtaAhciController.h
> + gEdkiiPeiAtaAhciHostControllerPpiGuid = { 0x61dd33ea, 0x421f, 0x4cc0,
> { 0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 0x61 } }
> +
> [Protocols]
>## Load File protocol provides capability to load and unload EFI image into
> memory and execute it.
># Include/Protocol/LoadPe32Image.h
> diff --git a/MdeModulePkg/Include/Ppi/AtaAhciController.h
> b/MdeModulePkg/Include/Ppi/AtaAhciController.h
> new file mode 100644
> index 00..2bdd53ff36
> --- /dev/null
> +++ b/MdeModulePkg/Include/Ppi/AtaAhciController.h
> @@ -0,0 +1,89 @@
> +/** @file
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved. This
> + program and the accompanying materials are licensed and made
> + available under the terms and conditions of the BSD License which
> + accompanies this distribution. The full text of the license may be
> + found at http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI_H_
> +#define _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI_H_
> +
> +#include
> +
> +///
> +/// Global ID for the EDKII_ATA_AHCI_HOST_CONTROLLER_PPI.
> +///
> +#define EDKII_ATA_AHCI_HOST_CONTROLLER_PPI_GUID \
> + { \
> +0x61dd33ea, 0x421f, 0x4cc0, { 0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1,
> +0xa2, 0x61 } \
> + }
> +
> +//
> +// Forward declaration for the EDKII_ATA_AHCI_HOST_CONTROLLER_PPI.
> +//
> +typedef struct _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI
> +EDKII_ATA_AHCI_HOST_CONTROLLER_PPI;
> +
> +/**
> + Get the MMIO base address of ATA AHCI host controller.
> +
> + @param[in] This The PPI instance pointer.
> + @param[in] ControllerId The ID of the ATA AHCI host controller.
> + @param[out] MmioBar The MMIO base address of the controller.
> +
> + @retval EFI_SUCCESS The operation succeeds.
> + @retval EFI_INVALID_PARAMETERThe parameters are invalid.
> + @retval EFI_NOT_FOUNDThe specified ATA AHCI host controller not
> found.
> +
> +**/
> +typedef
> +EFI_STATUS
> +(EFIAPI *EDKII_ATA_AHCI_HC_GET_MMIO_BAR) (
> + IN EDKII_ATA_AHCI_HOST_CONTROLLER_PPI*This,
> + IN UINT8 ControllerId,
> + OUT UINTN *MmioBar
> + );
> +
> +/**
> + Get the device path of ATA AHCI host controller.
> +
> + @param[in] This The PPI instance pointer.
> + @param[in] ControllerId The ID of the ATA AHCI host controller.
> + @param[out] DevicePathLength The length of the device path in bytes
> specified
> + by DevicePath.
> + @param[out] DevicePath The device path of ATA AHCI host
> controller.
> + This field re-uses EFI Device Path
> Protocol as
> + defined by Section 10.2 EFI Device Path
> Protocol
> + of UEFI 2.7 Specification.
> +
> + @retval EFI_SUCCESS The operation succeeds.
> + @retval EFI_INVALID_PARAMETERThe parameters are in
Re: [edk2] [PATCH v2 02/12] MdeModulePkg: Add definitions for EDKII PEI ATA PassThru PPI
Hao,
You could re-use the structure definition in AtaPassThru protocol.
For example: EFI_ATA_PASS_THRU_MODE v.s. EDKII_PEI_ATA_PASS_THRU_MODE
I see more duplicated structure definitions. We can avoid them.
Thanks,
Ray
> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, January 31, 2019 10:49 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Wang, Jian J ;
> Ni, Ray ; Dong, Eric
> Subject: [PATCH v2 02/12] MdeModulePkg: Add definitions for EDKII PEI ATA
> PassThru PPI
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409
>
> This commit will add the definitions for EDKII PEI ATA PassThru PPI. This PPI
> will provide services that allow ATA commands to be sent to ATA devices
> attached to an ATA controller in the PEI phase.
>
> More specifically, the PPI will provide services to:
>
> * Send ATA commands to an ATA device (by service 'PassThru');
> * Get the list of the attached ATA device on a controller (by services
> 'GetNextPort' and 'GetNextDevice');
> * Get the identification information (DevicePath) of the underlying ATA
> host controller (by service 'GetDevicePath').
>
> Cc: Jian J Wang
> Cc: Ruiyu Ni
> Cc: Eric Dong
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu
> ---
> MdeModulePkg/MdeModulePkg.dec | 3 +
> MdeModulePkg/Include/Ppi/AtaPassThru.h | 359
> 2 files changed, 362 insertions(+)
>
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec index 4411185073..8efb19e626
> 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -483,6 +483,9 @@
>## Include/Ppi/AtaAhciController.h
>gEdkiiPeiAtaAhciHostControllerPpiGuid = { 0x61dd33ea, 0x421f, 0x4cc0,
> { 0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 0x61 } }
>
> + ## Include/Ppi/AtaPassThru.h
> + gEdkiiPeiAtaPassThruPpiGuid = { 0xa16473fd, 0xd474, 0x4c89,
> { 0xae,
> 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 0x9 } }
> +
> [Protocols]
>## Load File protocol provides capability to load and unload EFI image into
> memory and execute it.
># Include/Protocol/LoadPe32Image.h
> diff --git a/MdeModulePkg/Include/Ppi/AtaPassThru.h
> b/MdeModulePkg/Include/Ppi/AtaPassThru.h
> new file mode 100644
> index 00..9281f0b833
> --- /dev/null
> +++ b/MdeModulePkg/Include/Ppi/AtaPassThru.h
> @@ -0,0 +1,359 @@
> +/** @file
> +
> + Copyright (c) 2019, Intel Corporation. All rights reserved. This
> + program and the accompanying materials are licensed and made
> + available under the terms and conditions of the BSD License which
> + accompanies this distribution. The full text of the license may be
> + found at http://opensource.org/licenses/bsd-license.php
> +
> + THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
> + WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
> +
> +**/
> +
> +#ifndef _EDKII_ATA_PASS_THRU_PPI_H_
> +#define _EDKII_ATA_PASS_THRU_PPI_H_
> +
> +#include
> +
> +///
> +/// Global ID for the EDKII_PEI_ATA_PASS_THRU_PPI.
> +///
> +#define EDKII_PEI_ATA_PASS_THRU_PPI_GUID \
> + { \
> +0xa16473fd, 0xd474, 0x4c89, { 0xae, 0xc7, 0x90, 0xb8, 0x3c, 0x73,
> +0x86, 0x9 } \
> + }
> +
> +//
> +// Forward declaration for the EDKII_PEI_ATA_PASS_THRU_PPI.
> +//
> +typedef struct _EDKII_PEI_ATA_PASS_THRU_PPI
> +EDKII_PEI_ATA_PASS_THRU_PPI;
> +
> +//
> +// Revision The revision to which the ATA Pass Thru PPI interface adheres.
> +// All future revisions must be backwards compatible.
> +// If a future version is not back wards compatible it is not the
> same
> GUID.
> +//
> +#define EDKII_PEI_ATA_PASS_THRU_PPI_REVISION 0x0001
> +
> +typedef struct {
> + UINT32Attributes;
> + UINT32IoAlign;
> +} EDKII_PEI_ATA_PASS_THRU_MODE;
> +
> +///
> +/// If this bit is set, then the EDKII_PEI_ATA_PASS_THRU_PPI interface
> +is for /// physical devices on the ATA controller.
> +///
> +#define EDKII_PEI_ATA_PASS_THRU_ATTRIBUTES_PHYSICAL 0x0001
> +///
> +/// If this bit is set, then the EDKII_PEI_ATA_PASS_THRU_PPI interface
> +is for /// logical devices on the ATA controller.
> +///
> +#define EDKII_PEI_ATA_PASS_THRU_ATTRIBUTES_LOGICAL 0x0002
> +
> +typedef struct {
> + UINT8Reserved1[2];
> + UINT8AtaStatus;
> + UINT8AtaError;
> + UINT8AtaSectorNumber;
> + UINT8AtaCylinderLow;
> + UINT8AtaCylinderHigh;
> + UINT8AtaDeviceHead;
> + UINT8AtaSectorNumberExp;
> + UINT8AtaCylinderLowExp;
> + UINT8AtaCy
Re: [edk2] [RFC] Proposal to split Pkgs
> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo > Ersek > Sent: Tuesday, January 29, 2019 7:12 PM > To: Ni, Ray ; edk2-devel@lists.01.org > Cc: Zimmer, Vincent ; Wolman, Ayellet > ; Cetola, Stephano ; > Kinney, Michael D > Subject: Re: [edk2] [RFC] Proposal to split Pkgs > > Hi Ray, > > On 01/29/19 06:59, Ni, Ray wrote: > > Hello, > > I'd like to propose to split today's BIG packages in following ways: > > > > ==Overview = > > > > 1. Separate Industry standard definitions from UEFI and PI interfaces. > > 2. Separate UEFI and PI interfaces from implementations. > > a. Separate UEFI and PI interfaces to different packages > > b. Separate PI PEI, DXE and MM phase interfaces to different > > packages 3. Separate different features into feature packages. > > Feature interface may be in the feature package to provide minimal > > common interface packages. > > > > The POC code is in https://github.com/jyao1/edk2/tree/ReOrg. > > It basically split the EDKII common code to three directories: > > Core/, Device/, and Feature/. > > The code is in very early POC phase and only code in Core/ directory > > can pass the build. > > I would like to gather feedbacks through this RFC to see whether this > > splitting direction makes sense. > > Is there any other better ways of splitting? > > Or perhaps do not split in such a small granularity? > > Or perhaps Mike's work to move lib-c content to edk2-libc repo, to > > move real platform code to edk2-platform repo is enough for now? > > > > ==More explanations = > > > > There are 9 packages inside Core/ directory: > > 1. BasePkg > > Contains industry standard definitions (exclude UEFI and PI) and base > > libraries that non-UEFI and non-PI development can depend on. > > UEFI or PI development can also depend on this package. > > 2. UefiPkg > > Contains UEFI interfaces and libraries that UEFI driver-model driver > > development can depend on. > > 3. PiPeiPkg > > Contains PI interfaces and libraries for PEI phase that PEI module > > development can depend on. > > 4. PiDxePkg > > Contains PI interfaces and libraries for DXE phase that DXE module > > development can depend on. > > 5. PiMmPkg > > Contains PI interfaces and libraries for MM phase that MM/SMM module > > development can depend on. > > 6. MdeModulePkg (TianoPkg? Name is still TBD) Contains Tiano > > implementation specific interfaces and libraries. > > Developing modules for pure UEFI or PI should not depend on this package. > > 7. PeiFoundationPkg > > Contains the PEI foundation modules (PeiCore and DxeIpl) and supported > > libraries. > > 8. DxeFoundationPkg > > Contains the DXE foundation modules (DxeCore and RuntimeDxe) and > > supported libraries. > > 9. SmmFoundationPkg > > Contains the SMM foundation modules (SmmCore, SmmIpl and > > SmmCommunicationBuffer) and supported libraries. > > > > These packages are positioned in different layers. The package in > > higher layer depends on all packages that are in lower layers. > > Layer 0: BasePkg. > > Layer 1: UefiPkg. > > Layer 2: PiPeiPkg > > Layer 3: PiDxePkg > > Layer 4: PiMmPkg > > Layer 5: MdeModulePkg (TianoPkg?) > > > > All other modules are put to small packages under Device/ or Feature/. > > > > == Benefit of this proposal = > > > > This helps to reduce the size of each package, especially the very BIG > > MdeModulePkg which contains almost all edk2 modules (except CPU, > > network, etc). So platform can use git sparse checkout feature to only > > clone the needed code still in package granularity. > > This also helps to separate the code maintenance to more expert > > developers. MdeModulePkg is just too huge to be maintained by 2 or 3 > > developers. > > from a first / quick skim, it sounds OK to me; however, I'd like to > explicitly defer > on this to the other stewards & stakeholders. I remember that Leif had ideas > about reorganizing the tree. That's great to have feedbacks in the early phase. > > (Also, I vaguely feel that the movement/renaming of some macros / definitions > that Andrew and Mike have been discussing in thread > > [edk2] History question about Base.h and its alternate parallel name > space Should we change it? > > might overlap with this reorg.) > > Regarding the benefits, I agree that we n
Re: [edk2] [PATCH v3 1/4] MdePkg/UefiSpec.h: Add definition to support Capsule-on-Disk feature
Where does the macro name come from?
If it's not defined in Spec, how about to rename it to
"EFI_CAPSULE_FILE_DIRECTORY"?
> -Original Message-
> From: edk2-devel On Behalf Of Chen A Chen
> Sent: Tuesday, January 29, 2019 3:44 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Zhang, Chao B
> ; Gao, Liming
> Subject: [edk2] [PATCH v3 1/4] MdePkg/UefiSpec.h: Add definition to support
> Capsule-on-Disk feature
>
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1482
>
> UEFI Spec define this definition to support Capsule-on-Disk.
>
> Cc: Michael D Kinney
> Cc: Liming Gao
> Cc: Zhang Chao B
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen
> ---
> MdePkg/Include/Uefi/UefiSpec.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/MdePkg/Include/Uefi/UefiSpec.h b/MdePkg/Include/Uefi/UefiSpec.h
> index 75af99de50..9d3d7a9a63 100644
> --- a/MdePkg/Include/Uefi/UefiSpec.h
> +++ b/MdePkg/Include/Uefi/UefiSpec.h
> @@ -2201,6 +2201,11 @@ typedef struct {
>#error Unknown Processor Type
> #endif
>
> +//
> +// The directory within the active EFI System Partition defined for
> +delivery of capsule to firmware //
> +#define EFI_CAPSULE_FROM_FILE_DIRL"\\EFI\\UpdateCapsule\\"
> +
> #include
> #include
> #include
> --
> 2.16.2.windows.1
>
> ___
> 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
[edk2] [RFC] Proposal to split Pkgs
Hello, I'd like to propose to split today's BIG packages in following ways: ==Overview = 1. Separate Industry standard definitions from UEFI and PI interfaces. 2. Separate UEFI and PI interfaces from implementations. a. Separate UEFI and PI interfaces to different packages b. Separate PI PEI, DXE and MM phase interfaces to different packages 3. Separate different features into feature packages. Feature interface may be in the feature package to provide minimal common interface packages. The POC code is in https://github.com/jyao1/edk2/tree/ReOrg. It basically split the EDKII common code to three directories: Core/, Device/, and Feature/. The code is in very early POC phase and only code in Core/ directory can pass the build. I would like to gather feedbacks through this RFC to see whether this splitting direction makes sense. Is there any other better ways of splitting? Or perhaps do not split in such a small granularity? Or perhaps Mike's work to move lib-c content to edk2-libc repo, to move real platform code to edk2-platform repo is enough for now? ==More explanations = There are 9 packages inside Core/ directory: 1. BasePkg Contains industry standard definitions (exclude UEFI and PI) and base libraries that non-UEFI and non-PI development can depend on. UEFI or PI development can also depend on this package. 2. UefiPkg Contains UEFI interfaces and libraries that UEFI driver-model driver development can depend on. 3. PiPeiPkg Contains PI interfaces and libraries for PEI phase that PEI module development can depend on. 4. PiDxePkg Contains PI interfaces and libraries for DXE phase that DXE module development can depend on. 5. PiMmPkg Contains PI interfaces and libraries for MM phase that MM/SMM module development can depend on. 6. MdeModulePkg (TianoPkg? Name is still TBD) Contains Tiano implementation specific interfaces and libraries. Developing modules for pure UEFI or PI should not depend on this package. 7. PeiFoundationPkg Contains the PEI foundation modules (PeiCore and DxeIpl) and supported libraries. 8. DxeFoundationPkg Contains the DXE foundation modules (DxeCore and RuntimeDxe) and supported libraries. 9. SmmFoundationPkg Contains the SMM foundation modules (SmmCore, SmmIpl and SmmCommunicationBuffer) and supported libraries. These packages are positioned in different layers. The package in higher layer depends on all packages that are in lower layers. Layer 0: BasePkg. Layer 1: UefiPkg. Layer 2: PiPeiPkg Layer 3: PiDxePkg Layer 4: PiMmPkg Layer 5: MdeModulePkg (TianoPkg?) All other modules are put to small packages under Device/ or Feature/. == Benefit of this proposal = This helps to reduce the size of each package, especially the very BIG MdeModulePkg which contains almost all edk2 modules (except CPU, network, etc). So platform can use git sparse checkout feature to only clone the needed code still in package granularity. This also helps to separate the code maintenance to more expert developers. MdeModulePkg is just too huge to be maintained by 2 or 3 developers. Thanks, Ray ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] MdePkg/BaseLib: Add Base64Encode() and Base64Decode()
Minor comments regarding the parameter name. > -Original Message- > From: edk2-devel On Behalf Of Shenglei > Zhang > Sent: Thursday, January 10, 2019 8:44 PM > To: edk2-devel@lists.01.org > Cc: Kinney, Michael D ; Gao, Liming > > Subject: [edk2] [PATCH v2] MdePkg/BaseLib: Add Base64Encode() and > Base64Decode() > > Introduce public functions Base64Encode and Base64Decode. > https://bugzilla.tianocore.org/show_bug.cgi?id=1370 > > v2:1.Remove some white space. >2.Add unit test with test vectors in RFC 4648. > https://github.com/shenglei10/edk2/tree/encode_test > https://github.com/shenglei10/edk2/tree/decode_test > > Cc: Michael D Kinney > Cc: Liming Gao > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Shenglei Zhang > --- > MdePkg/Include/Library/BaseLib.h | 56 + > MdePkg/Library/BaseLib/String.c | 345 > +++ > 2 files changed, 401 insertions(+) > > diff --git a/MdePkg/Include/Library/BaseLib.h > b/MdePkg/Include/Library/BaseLib.h > index 1eb842384e..9317888a7e 100644 > --- a/MdePkg/Include/Library/BaseLib.h > +++ b/MdePkg/Include/Library/BaseLib.h > @@ -2720,6 +2720,62 @@ AsciiStrnToUnicodeStrS ( >OUT UINTN *DestinationLength >); > > +/** > + Convert binary data to a Base64 encoded ascii string based on RFC4648. > + > + Produce a Null-terminated Ascii string in the output buffer specified by > AsciiPtr and AsciiSize. > + The Ascii string is produced by converting the data string specified by > DataPtr and DataLen. > + > + @param DataPtr Input UINT8 data > + @param DataLenNumber of UINT8 bytes of data > + @param AsciiPtr Pointer to output string buffer > + @param AsciiSize Size of ascii buffer. Set to 0 to get the size needed. > + Caller is responsible for passing in > + buffer of AsciiSize > + > + @retval RETURN_SUCCESSWhen ascii buffer is filled in. > + @retval RETURN_INVALID_PARAMETER If DataPtr is NULL or AsciiSize is > NULL. > + @retval RETURN_INVALID_PARAMETER If DataLen or AsciiSize is too big. > + @retval RETURN_BUFFER_TOO_SMALL If DataLen is 0 and AsciiSize is <1. > + @retval RETURN_BUFFER_TOO_SMALL If AsciiPtr is NULL or too small. > + > +**/ > +RETURN_STATUS > +EFIAPI > +Base64Encode ( > + IN CONST UINT8 *DataPtr, 1. Data or Source? > + INUINTN DataLen, 2. DataLength or SourceLength? > + OUT CHAR8 *AsciiPtr OPTIONAL, 3. AsciiString or Destination? > + IN OUTUINTN *AsciiSize 4. AsciiStringSize or DestinationSize? > + ); > + > +/** > + Convert Base64 ascii string to binary data based on RFC4648. > + > + Produce Null-terminated binary data in the output buffer specified by > BinPtr and BinSize. > + The binary data is produced by converting the Base64 ascii string specified > by DataPtr and DataLen. > + > + @param DataPtr Input ASCII characters > + @param DataLen Number of ASCII characters > + @param BinPtrPointer to output buffer > + @param BinSize Caller is responsible for passing in buffer of at least > BinSize. > +Set 0 to get the size needed. Set to bytes > stored on return. > + > + @retval RETURN_SUCCESSWhen binary buffer is filled in. > + @retval RETURN_INVALID_PARAMETER If DataPtr is NULL or BinSize is > NULL. > + @retval RETURN_INVALID_PARAMETER If DataLen or BinSize is too big. > + @retval RETURN_INVALID_PARAMETER If BinPtr NULL and BinSize != 0. > + @retval RETURN_INVALID_PARAMETER If there is any Invalid character in > input stream. > + @retval RETURN_BUFFER_TOO_SMALL If Buffer length is too small. > + **/ > +RETURN_STATUS > +EFIAPI > +Base64Decode ( > + IN CONST CHAR8 *DataPtr, 5. AsciiString or Source? At least I don't think "DataPtr" is proper here. It's not the same "DataPtr" in Encode() API. > + INUINTN DataLen, 6. AsciiStringLength or SourceLength? > + OUT UINT8 *BinPtr OPTIONAL, 7. Data or Destination? > + IN OUTUINTN *BinSize 8. DataSize or DestinationSize? > + ); > + > /** >Converts an 8-bit value to an 8-bit BCD value. > > diff --git a/MdePkg/Library/BaseLib/String.c > b/MdePkg/Library/BaseLib/String.c index e6df12797d..761ff6830a 100644 > --- a/MdePkg/Library/BaseLib/String.c > +++ b/MdePkg/Library/BaseLib/String.c > @@ -1763,6 +1763,351 @@ AsciiStrToUnicodeStr ( > > #endif > > +// > +// The basis for Base64 encoding is RFC 4686 > +https://tools.ietf.org/html/rfc4648 > +// > +// RFC 4686 has a number of MAY and SHOULD cases. This implementation > +chooses // the more restrictive versions for security concerns (see RFC 4686 > section 3.3). > +// > +// A invalid character, if encountered during the decode operation, > +causes the data // to be rejected. In addition, the '=' padding > +character is only allowed at the end // of the Base64 encoded string. > +// > +#define BAD_V 99 > + > +STATIC CHAR8
Re: [edk2] [PATCH v2 2/2] MdePkg/UefiDevicePathLib: Add a checking step
Reviewed-by: Ruiyu Ni
> -Original Message-
> From: edk2-devel On Behalf Of Shenglei
> Zhang
> Sent: Wednesday, December 12, 2018 11:10 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming
>
> Subject: [edk2] [PATCH v2 2/2] MdePkg/UefiDevicePathLib: Add a checking
> step
>
> Add a checking step in DevicePathUtilities.c to verify the DevicePath.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1372
>
> v2: Remove ASSERT() and the redundant checking step.
> Update related description in DevicePathLib.h
>
> Cc: Liming Gao
> Cc: Michael D Kinney
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> ---
> MdePkg/Include/Library/DevicePathLib.h | 2 +-
> .../UefiDevicePathLib/DevicePathUtilities.c| 14 ++
> 2 files changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/MdePkg/Include/Library/DevicePathLib.h
> b/MdePkg/Include/Library/DevicePathLib.h
> index 959299704a..717d4db42f 100644
> --- a/MdePkg/Include/Library/DevicePathLib.h
> +++ b/MdePkg/Include/Library/DevicePathLib.h
> @@ -22,7 +22,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>
> /**
>Determine whether a given device path is valid.
> - If DevicePath is NULL, then ASSERT().
> + If DevicePath is NULL or the size is not suitable, then return false.
>
>@param DevicePath A pointer to a device path data structure.
>@param MaxSize The maximum size of the device path data structure.
> diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> b/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> index 665e5a4adc..05f82c1313 100644
> --- a/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> +++ b/MdePkg/Library/UefiDevicePathLib/DevicePathUtilities.c
> @@ -59,19 +59,17 @@ IsDevicePathValid (
>UINTN Size;
>UINTN NodeLength;
>
> - ASSERT (DevicePath != NULL);
> -
> - if (MaxSize == 0) {
> -MaxSize = MAX_UINTN;
> - }
> -
>//
> - // Validate the input size big enough to touch the first node.
> + //Validate the input whether exists and its size big enough to touch the
> first node
>//
> - if (MaxSize < sizeof (EFI_DEVICE_PATH_PROTOCOL)) {
> + if (DevicePath == NULL || (MaxSize > 0 && MaxSize <
> END_DEVICE_PATH_LENGTH)) {
> return FALSE;
>}
>
> + if (MaxSize == 0) {
> +MaxSize = MAX_UINTN;
> + }
> +
>for (Count = 0, Size = 0; !IsDevicePathEnd (DevicePath); DevicePath =
> NextDevicePathNode (DevicePath)) {
> NodeLength = DevicePathNodeLength (DevicePath);
> if (NodeLength < sizeof (EFI_DEVICE_PATH_PROTOCOL)) {
> --
> 2.18.0.windows.1
>
> ___
> 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
Re: [edk2] Drop CSM support in OvmfPkg?
David, I think we got an agreement here to move CSM components in OvmfPkg. I prefer we firstly clone the required CSM components in OvmfPkg right no. Finally I can remove the IntelFrameworkModulePkg/IntelFrameworkPkg in one patch. (I say "finally" because OVMF CSM dependency is not the only case that prevent removing the two framework packages.) Would you like to do the clone? Or if you are busy, I can do that. Thanks, Ray > -Original Message- > From: David Woodhouse [mailto:dw...@infradead.org] > Sent: Wednesday, January 23, 2019 5:49 PM > To: Laszlo Ersek ; Ni, Ray ; Gerd > Hoffmann ; Richardson, Brian > > Cc: Justen, Jordan L ; edk2-devel@lists.01.org; > Kevin O'Connor ; Anthony Perard > > Subject: Re: Drop CSM support in OvmfPkg? > > On Wed, 2019-01-23 at 10:46 +0100, Laszlo Ersek wrote: > > I'm fine if we move the generic CSM components into OvmfPkg, however I'm > > going to ask David to assume reviewer responsibilities for them. > > > > Given the current format of "Maintainers.txt", we couldn't spell out the > > exact pathnames of the CSM components, so we'd add a line like > > > > R: David Woodhouse > > > > under OvmfPkg. There is "prior art" for this pattern, see: > > > > R: Anthony Perard > > R: Julien Grall > > > > Because Anthony and Julien are the authority on Xen-related code under > > OvmfPkg. (See commit 337fe6a06eda, "Maintainers.txt: add Xen reviewers > > to OvmfPkg", 2017-09-26.) > > > > > > If we keep CSM support in OvmfPkg in any form at all, then I would > > prefer holding all the related stuff in the core edk2 repository (with > > the above Reviewership), over requiring people to deal with multiple > > repositories. I agree (from experience) that PACKAGES_PATH / multiple > > workspaces work fine, but in this case I think keeping one shared > > history is an advantage. > > This all makes sense to me. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
