Re: [edk2] [Patch] NetworkPkg/IScsiDxe: Fix the incorrect error handling in DriverEntryPoint

Reviewed-by: Zhang Lubo > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin > Wu > Sent: Wednesday, March 22, 2017 9:33 AM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Zhang, Lubo

Re: [edk2] [PATCH v1 0/9] *** Upgrade CryptoPkg to use the latest OpenSSL 1.1.0xx/stable release ***

> -Original Message- > From: Gao, Liming > Sent: Wednesday, March 22, 2017 10:23 AM > To: Long, Qin; edk2-devel@lists.01.org > Cc: ard.biesheu...@linaro.org; Ye, Ting; ronald.c...@arm.com; Wu, Jiaxin; > g...@suse.com; ler...@redhat.com > Subject: RE: [edk2] [PATCH v1 0/9] *** Upgrade

Re: [edk2] [PATCH v1 0/9] *** Upgrade CryptoPkg to use the latest OpenSSL 1.1.0xx/stable release ***

Long: I find several issues. Could you help clarify them? 1. OpenSsl branch should be OpenSSL_1_1_0-stable instead of OpenSSL_1_1_0e. Could you update OpenSSL-HOWTO.txt? 2. process_files.pl in CryptoPkg\Library\OpensslLib still required? 3. $(OPENSSL_PATH)/crypto/aes/aes_cbc.c exists in the

Re: [edk2] Do edk2 support PcdGetEx64 in library

Hi Xiaofeng, Just sent out the patch BaseTools: Fix build failure for DynamicEx Pcd used in the Library Thanks. Best Regards, Zhu Yonghong -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, Liming Sent: Monday, March 13, 2017 10:34 AM To:

[edk2] [Patch] BaseTools: Fix build failure for DynamicEx Pcd used in the Library

Update DynExPcdTokenNumberMapping logic, currently even it is Library, its self's Pcd is saved into ModulePcdList. Fixes:https://bugzilla.tianocore.org/show_bug.cgi?id=434 Cc: Liming Gao Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Yonghong Zhu

Re: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3] Add SSDT table tool.

Reviewed-by: zwei4 Thanks, David Wei -Original Message- From: Lu, ShifeiX A Sent: Tuesday, March 21, 2017 5:28 PM To: edk2-devel@lists.01.org Cc: Wei, David Subject:

[edk2] [Patch] NetworkPkg/IScsiDxe: Fix the incorrect error handling in DriverEntryPoint

Currently, error handling in IScsiDriverEntryPoint is incorrect. For example, if IScsiCreateAttempts() return error due to the limited max variable size, iSCSI will not unload the configuration entries. Cc: Zhang Lubo Cc: Ye Ting Cc: Fu Siyuan

Re: [edk2] [PATCH v1 9/9] CryptoPkg/TlsLib: Update TLS Wrapper Library to align with OpenSSL changes.

Thomas, Thanks for the comments. I will check this with Jiaxin, and make the possible updates in V2. Best Regards & Thanks, LONG, Qin > -Original Message- > From: Palmer, Thomas [mailto:thomas.pal...@hpe.com] > Sent: Wednesday, March 22, 2017 1:43 AM > To: Long, Qin;

[edk2] [PATCH 2/2] MdeModulePkg/Ufs: Wait fDeviceInit be cleared by devices during init

In the origin codes, the host sets the fDeviceInit flag to initiate device initialization, but does not check whether the device resets this flag to indicate the device initialization is completed. Details can be referred at UFS 2.0 Spec Section 14.2 - Flags. Cc: Feng Tian

[edk2] [PATCH 0/2] MdeModulePkg/Ufs: Wait fDeviceInit be cleared by devices during init

The series changes the UFS host to wait for the device to clear the 'fDeviceInit' bit by a device after setting this flag. The series also cleans up the usages of 'EFI_D_XXX' and replaces them with 'DEBUG_XXX' in DEBUG(). Cc: Feng Tian Hao Wu (2):

[edk2] [PATCH 1/2] MdeModulePkg/UfsPassThruDxe: Replace 'EFI_D_XXX' with 'DEBUG_XXX'

Cc: Feng Tian Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Hao Wu --- MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c| 26 MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThruHci.c | 70 ++-- 2 files

Re: [edk2] [PATCH] MdeModulePkg/MemoryProtection: split protect and unprotect paths

On 21 March 2017 at 14:14, Yao, Jiewen wrote: > Good idea. > > Reviewed-by: jiewen@intel.com > Pushed, thanks. > > >> -Original Message- >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >> Sent: Tuesday, March 21, 2017 9:49 PM >> To:

[edk2] [RFC PATCH v2 10/10] OvmfPkg/QemuVideoDxe: Clear the C-bit from framebuffer region when SEV is enabled

Since the framebuffer memory region is shared between the guest and hypervisor hence we must clear the memory encryption bit from this memory region when SEV is enabled. Signed-off-by: Brijesh Singh --- OvmfPkg/QemuVideoDxe/Gop.c| 15 +++

[edk2] [RFC PATCH v2 08/10] OvmfPkg/QemuFwCfgLib: Provide Pei and Dxe specific library support

Current QemuFwCfgLib.inf is used in both Pei and Dxe phases. The patch adds Pei and Dxe inf file to provide a seperate QemuFwCfg library for Pei and Dxe phases. There is no code change in this patch other than rearranging the files and updating inf files. The patch is precursor to add SEV support

[edk2] [RFC PATCH v2 07/10] OvmfPkg/BmDmaLib: Add SEV support

When SEV is enabled, the DMA operations must be performed on a shared (i.e unencrypted) pages. The patch adds SEV specific hooks to use the bounce buffer when caller map/unmap host address to a DMA address and similarly clears/set memory encryption attribute when caller allocates or free the DMA

[edk2] [RFC PATCH v2 01/10] OvmfPkg/Include: Define SEV specific CPUID and MSR

The patch defines AMD's Memory Encryption Information CPUID leaf (0x8000_001F). The complete description for this CPUID leaf is available in APM volume 2 [1] Section 15.34 (Secure Encrypted Virtualization). [1] http://support.amd.com/TechDocs/24593.pdf Signed-off-by: Brijesh Singh

[edk2] [RESEND] [RFC PATCH v2 00/10] x86: Secure Encrypted Virtualization (AMD)

(Sorry for churn, correcting Laszlo's email address) This RFC series provides support for AMD's new Secure Encrypted Virtualization (SEV) feature. SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. The SEV feature allows the

[edk2] [RFC PATCH v2 06/10] OvmfPkg/DxeBmDmaLib: Fix AllocateBounceBuffer parameter

The patch fixes AllocateBounceBuffer parameters. Signed-off-by: Brijesh Singh --- OvmfPkg/Library/DxeBmDmaLib/DxeBmDmaLib.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OvmfPkg/Library/DxeBmDmaLib/DxeBmDmaLib.c

[edk2] [RFC PATCH v2 02/10] OvmfPkg/ResetVector: add memory encryption mask when SEV is enabled

SEV guest VMs have the concept of private and shared memory. Private memory is encrypted with the guest-specific key, while shared memory may be encrypted with hypervisor key. Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the

[edk2] [RFC PATCH v2 09/10] OvmfPkg/QemuFwCfgLib: Add Secure Encrypted Virtualization (SEV) support

The patch adds SEV support in QemuFwCfgLib. When SEV is enabled: * Pei phase support IO-style operations. This is mainly because we need to use a bounce buffer inorder to support DMA operation. Allocate a memory for bounce buffer can get painful in Pei phase hence if we detect FWCfg DMA

[edk2] [RFC PATCH v2 05/10] OvmfPkg/DxeBmDmaLib: Import DxeBmDmaLib package

Import DxeBmDmaLib package in OvmfPkg, we need to modify the package to include SEV support. The BmDmaLib is proposed by Leo Duran https://lists.01.org/pipermail/edk2-devel/2017-March/008109.html Signed-off-by: Brijesh Singh --- OvmfPkg/Include/Library/BmDmaLib.h

[edk2] [RFC PATCH v2 04/10] OvmfPkg/BaseMemcryptSevLib: Add SEV helper library

Add Secure Encrypted Virtualization (SEV) helper library. The library provides the routines to set or clear memory encryption bit for a given memory region and functions to check whether SEV is enabled. Signed-off-by: Brijesh Singh ---

[edk2] [RFC PATCH v2 03/10] OvmfPkg/PlatformPei: Add Secure Encrypted Virutualization (SEV) support

Initialize Secure Encrypted Virtualization support and set the memory encryption mask PCD. Signed-off-by: Brijesh Singh --- OvmfPkg/OvmfPkgIa32.dsc |3 + OvmfPkg/OvmfPkgIa32X64.dsc |3 + OvmfPkg/OvmfPkgX64.dsc |3 +

[edk2] [RFC PATCH v2 10/10] OvmfPkg/QemuVideoDxe: Clear the C-bit from framebuffer region when SEV is enabled

Since the framebuffer memory region is shared between the guest and hypervisor hence we must clear the memory encryption bit from this memory region when SEV is enabled. Signed-off-by: Brijesh Singh --- OvmfPkg/QemuVideoDxe/Gop.c| 15 +++

[edk2] [RFC PATCH v2 06/10] OvmfPkg/DxeBmDmaLib: Fix AllocateBounceBuffer parameter

The patch fixes AllocateBounceBuffer parameters. Signed-off-by: Brijesh Singh --- OvmfPkg/Library/DxeBmDmaLib/DxeBmDmaLib.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/OvmfPkg/Library/DxeBmDmaLib/DxeBmDmaLib.c

[edk2] [RFC PATCH v2 09/10] OvmfPkg/QemuFwCfgLib: Add Secure Encrypted Virtualization (SEV) support

The patch adds SEV support in QemuFwCfgLib. When SEV is enabled: * Pei phase support IO-style operations. This is mainly because we need to use a bounce buffer inorder to support DMA operation. Allocate a memory for bounce buffer can get painful in Pei phase hence if we detect FWCfg DMA

[edk2] [RFC PATCH v2 08/10] OvmfPkg/QemuFwCfgLib: Provide Pei and Dxe specific library support

Current QemuFwCfgLib.inf is used in both Pei and Dxe phases. The patch adds Pei and Dxe inf file to provide a seperate QemuFwCfg library for Pei and Dxe phases. There is no code change in this patch other than rearranging the files and updating inf files. The patch is precursor to add SEV support

[edk2] [RFC PATCH v2 07/10] OvmfPkg/BmDmaLib: Add SEV support

When SEV is enabled, the DMA operations must be performed on a shared (i.e unencrypted) pages. The patch adds SEV specific hooks to use the bounce buffer when caller map/unmap host address to a DMA address and similarly clears/set memory encryption attribute when caller allocates or free the DMA

[edk2] [RFC PATCH v2 05/10] OvmfPkg/DxeBmDmaLib: Import DxeBmDmaLib package

Import DxeBmDmaLib package in OvmfPkg, we need to modify the package to include SEV support. The BmDmaLib is proposed by Leo Duran https://lists.01.org/pipermail/edk2-devel/2017-March/008109.html Signed-off-by: Brijesh Singh --- OvmfPkg/Include/Library/BmDmaLib.h

[edk2] [RFC PATCH v2 04/10] OvmfPkg/BaseMemcryptSevLib: Add SEV helper library

Add Secure Encrypted Virtualization (SEV) helper library. The library provides the routines to set or clear memory encryption bit for a given memory region and functions to check whether SEV is enabled. Signed-off-by: Brijesh Singh ---

[edk2] [RFC PATCH v2 03/10] OvmfPkg/PlatformPei: Add Secure Encrypted Virutualization (SEV) support

Initialize Secure Encrypted Virtualization support and set the memory encryption mask PCD. Signed-off-by: Brijesh Singh --- OvmfPkg/OvmfPkgIa32.dsc |3 + OvmfPkg/OvmfPkgIa32X64.dsc |3 + OvmfPkg/OvmfPkgX64.dsc |3 +

[edk2] [RFC PATCH v2 00/10] x86: Secure Encrypted Virtualization (AMD)

This RFC series provides support for AMD's new Secure Encrypted Virtualization (SEV) feature. SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. The SEV feature allows the memory contents of a virtual machine (VM) to be

[edk2] [RFC PATCH v2 02/10] OvmfPkg/ResetVector: add memory encryption mask when SEV is enabled

SEV guest VMs have the concept of private and shared memory. Private memory is encrypted with the guest-specific key, while shared memory may be encrypted with hypervisor key. Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the

[edk2] [RFC PATCH v2 01/10] OvmfPkg/Include: Define SEV specific CPUID and MSR

The patch defines AMD's Memory Encryption Information CPUID leaf (0x8000_001F). The complete description for this CPUID leaf is available in APM volume 2 [1] Section 15.34 (Secure Encrypted Virtualization). [1] http://support.amd.com/TechDocs/24593.pdf Signed-off-by: Brijesh Singh

Re: [edk2] [PATCH v1 9/9] CryptoPkg/TlsLib: Update TLS Wrapper Library to align with OpenSSL changes.

Qin, Please update TlsSetVersion to use SSL_CTX_set_min_proto_version and SSL_CTX_set_max_proto_version in the switch statement. We do not want auto-negotitate but only to restrict to a particular version. Also, lets update TlsCtxNew to use only SSL_CTX_set_min_proto_version. TlsCtxNew

[edk2] [PATCH v1 9/9] CryptoPkg/TlsLib: Update TLS Wrapper Library to align with OpenSSL changes.

This patch update the wrapper implementation in TlsLib to align with the latest OpenSSL-1.1.0xx API changes. Cc: Jiaxin Wu Cc: Ting Ye Cc: Laszlo Ersek Cc: Ard Biesheuvel Cc: Gary Lin Cc:

[edk2] [PATCH v1 2/9] CryptoPkg/OpensslLib: Remove patch file and installation scripts.

This patch removes the EDKII-openssl-.patch, installation scripts and old opensslconf.h. And old Patch-HOWTO.txt was replaced by OpenSSL-HOWTO.txt to state how to download the latest OpenSSL sources for build. Cc: Ting Ye Cc: Laszlo Ersek Cc: Ard

[edk2] [PATCH v1 6/9] CryptoPkg: Add extra build option to disable VS build warning

openssl/include/openssl/lhash.h will bring C4090 build warning issue, which is one known issue for OpenSSL under Visual Studio toolchain. See more discussions at https://github.com/openssl/openssl/issues/2214. Use /wd4090 to silence this build warning until OpenSSL fix this. Cc: Ting Ye

[edk2] [PATCH v1 3/9] CryptoPkg: Fix handling of function pointers

In a couple of places, OpenSSL code uses the address of the strcmp() function, and assigns it to another comparator function pointer. Unfortunately, this falls foul of the inconsistent function ABI that we use in EDKII. We '#define strcmp AsciiStrCmp' but AsciiStrCmp is an EFIAPI function with

[edk2] [PATCH v1 7/9] CryptoPkg: Update HMAC Wrapper implementation with opaque HMAC_CTX object.

OpenSSL-1.1.xx makes most data structures opaque. This patch updated HMAC Wrapper implementation with opaque HMAC_CTX object. The HmacXXGetContextSize() was updated to use the fixed HMAC_CTX size, which is just kept for compatibility. And add new APIs (HmacXXNew(), HmacXXFree()) as the recommended

[edk2] [PATCH v1 5/9] CryptoPkg: Clean-up CRT Library Wrapper.

Cleaning-up CRT Library Wrapper for the third-party cryptographic library building. The changes includes 1. Rename OpenSslSupport.h to CrtLibSupport.h for future alternative crypto provider support. 2. Remove all un-referenced CRT APIs and headers. (NOTE: More cleans-up could be possible after

[edk2] [PATCH v1 1/9] CryptoPkg/OpensslLib: Update INF files to support OpenSSL-1.1.0xx build.

Update OpensslLib INF files to support OpenSSL-1.1.0xx source build. The file list was generated from the latest OpenSSL-1.1.0e release. Main changes to support OpensslLib build in this patch include: 1. Use "openssl" instead of "openssl-x.x.xx" as main source directory, Also update include

[edk2] [PATCH v1 0/9] *** Upgrade CryptoPkg to use the latest OpenSSL 1.1.0xx/stable release ***

(https://github.com/qloong/edk2/tree/dev-openssl-stable) Current EDKII-CryptoPkg is leveraging OpenSSL-1.0.2xx as the underlying cryptographic provider, which requires some extra patches (EDKII-openssl-.patch) and installation scripts for EDKII build & usage. The latest stable version of

[edk2] ASSERT with PXE IPv6 boot.

Hello all, I've a Windows Deployment Services PXE server supporting IPv6 with Windows 10 installers present. I've been getting ASSERT with PXE IPv6 in the following scenario. 1) Enable IPv6 Support 2) PXE Boot to Win 10 installer 3) Cancel the install process (Causes system to reboot) 4)

Re: [edk2] [PATCH] MdeModulePkg/MemoryProtection: split protect and unprotect paths

Good idea. Reviewed-by: jiewen@intel.com > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Tuesday, March 21, 2017 9:49 PM > To: edk2-devel@lists.01.org; Yao, Jiewen > Cc: Zeng, Star ; Tian, Feng

[edk2] [PATCH] MdeModulePkg/MemoryProtection: split protect and unprotect paths

Currently, the PE/COFF image memory protection code uses the same code paths for protecting and unprotecting an image. This is strange, since unprotecting an image involves a single call into the CPU arch protocol to clear the permission attributes of the entire range, and there is no need to

Re: [edk2] [PATCH 0/2] ArmVirtPkg/HighMemDxe: fix issues reported by Michael

On 21 March 2017 at 09:23, Ard Biesheuvel wrote: > This fixes two separate issues reported by Michael: > - setting EFI_MEMORY_XP via the GCD memory space map always fails, > - patchable PCD updates do not propagate to other modules. > > Ard Biesheuvel (2): >

Re: [edk2] [PATCH 2/2] ArmVirtPkg/HighMemDxe: check new regions against GCD memory space map

On 03/21/17 10:23, Ard Biesheuvel wrote: > Instead of looking at the PCD gArmTokenSpaceGuid.PcdSystemMemoryBase > to decide which DT node covers the memory we are already using, query > the GCD memory space map, which is the authoritative source for this > kind of information > > This fixes a

Re: [edk2] [PATCH 1/2] ArmVirtPkg/HighMemDxe: use CPU arch protocol to apply memprotect policy

On 03/21/17 10:23, Ard Biesheuvel wrote: > Instead of invoking gDS->SetMemorySpaceAttributes to set the EFI_MEMORY_XP > attribute on newly added regions, which is guaranteed to fail if the same > attribute was not declared as a capability of the region when it as added, > invoke the CPU arch

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3] Add SSDT table tool.

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: lushifex --- .../Common/Application/SsdtUpdate/SsdtUpdate.asl | 29 +++ .../Common/Application/SsdtUpdate/SsdtUpdate.c | 199 + .../Common/Application/SsdtUpdate/SsdtUpdate.h

[edk2] [PATCH 1/2] ArmVirtPkg/HighMemDxe: use CPU arch protocol to apply memprotect policy

Instead of invoking gDS->SetMemorySpaceAttributes to set the EFI_MEMORY_XP attribute on newly added regions, which is guaranteed to fail if the same attribute was not declared as a capability of the region when it as added, invoke the CPU arch protocol directly to set the EFI_MEMORY_XP attribute

[edk2] [PATCH 2/2] ArmVirtPkg/HighMemDxe: check new regions against GCD memory space map

Instead of looking at the PCD gArmTokenSpaceGuid.PcdSystemMemoryBase to decide which DT node covers the memory we are already using, query the GCD memory space map, which is the authoritative source for this kind of information This fixes a problem observed by Michael on platforms where this PCD

[edk2] [PATCH 0/2] ArmVirtPkg/HighMemDxe: fix issues reported by Michael

This fixes two separate issues reported by Michael: - setting EFI_MEMORY_XP via the GCD memory space map always fails, - patchable PCD updates do not propagate to other modules. Ard Biesheuvel (2): ArmVirtPkg/HighMemDxe: use CPU arch protocol to apply memprotect policy

Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library

On 03/21/17 09:41, Zeng, Star wrote: > It is not been implemented yet. Just for our discussion. I should use future > tense in the sentence, sorry. Ah, I see. Yeah, it makes sense. (Although it still wouldn't allow us to avoid a NULL class library plug-in for AcpiTableDxe, for setting the PCD

Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library

On 03/21/17 09:43, Ard Biesheuvel wrote: > On 21 March 2017 at 07:10, Ard Biesheuvel wrote: >> On 21 March 2017 at 02:27, Zeng, Star wrote: >>> Just an idea. >>> >> >> I like it! >> >>> There is a way to do not introduce a new PCD, but reuse >>>

Re: [edk2] [PATCH v5 00/11] Add CPU features driver

Series Reviewed-by: Feng Tian Thanks Feng -Original Message- From: Fan, Jeff Sent: Monday, March 20, 2017 4:20 PM To: edk2-devel@lists.01.org Cc: Tian, Feng ; Kinney, Michael D Subject: [PATCH v5 00/11] Add CPU

Re: [edk2] [Patch 0/2] Fix potential ASSERT if NetIp4IsUnicast is called

Series Reviewed-by: Sriram Subramanian -Original Message- From: Jiaxin Wu [mailto:jiaxin...@intel.com] Sent: Tuesday, March 21, 2017 9:13 AM To: edk2-devel@lists.01.org Cc: Hegde, Nagaraj P ; Subramanian, Sriram ; Zhang Lubo

Re: [edk2] [PATCH v2] ShellPkg/tftp: Add one option for tftp command to specify windowsize

Reviewed-by: Ye Ting -Original Message- From: Wu, Jiaxin Sent: Friday, March 17, 2017 9:22 AM To: edk2-devel@lists.01.org Cc: Ye, Ting ; Fu, Siyuan ; Carsey, Jaben ; Wu, Jiaxin

Re: [edk2] [PATCH] MdeModulePkg/BootGraphicsResourceTableDxe: don't allocate below 4 GB

On 21 March 2017 at 02:37, Gao, Liming wrote: > Yes. Spec has no such limitation. I agree this change. > > Reviewed-by: Liming Gao > Pushed as 09da11081915, thanks. > Thanks > Liming >>-Original Message- >>From: Zeng, Star >>Sent: Monday,

Re: [edk2] [Patch 0/2] Fix potential ASSERT if NetIp4IsUnicast is called

Series Reviewed-by: Ye Ting -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Hegde, Nagaraj P Sent: Tuesday, March 21, 2017 12:59 PM To: Wu, Jiaxin ; edk2-devel@lists.01.org Cc: Ye, Ting

Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library

On 21 March 2017 at 02:27, Zeng, Star wrote: > Just an idea. > I llike it! > There is a way to do not introduce a new PCD, but reuse > PcdAcpiExposedTableVersions. > When PcdAcpiExposedTableVersions is configured to *0* (means no ANY ACPI > table should be exposed),

Re: [edk2] visibility pf PcdSet

On 21 March 2017 at 02:23, Gao, Liming wrote: > Yes. Feature, FixedAtBuild and PatchableInModule PCD are module level; > Dyanmic and DynamicEx are platform level. > If you have case to share the data between the different modules, you can > configure PCD as Dynamic PCD. >

Re: [edk2] [PATCH] MdeModulePkg/AcpiTableDxe: consider version mask when removing tables

On 21 March 2017 at 01:28, Zeng, Star wrote: > Reviewed-by: Star Zeng > Pushed as f859c6796f40, thanks > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, March 20, 2017 10:52 PM > To: