Re: [edk2] Page Table initialization and update in SMM mode

Hi Laszlo Thanks for the reminder. Hi William I try to your answer below. Feel free to let me know if you have more question. For more detail information on how we protect SMRAM, please refer to https://www.gitbook.com/book/edk2-docs/a-tour-beyond-bios-memory-protection-in-uefi-bios/details

Re: [edk2] [PATCH v3 09/12] ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL dynamically

On 24 March 2017 at 22:38, Laszlo Ersek wrote: > In this patch, the ACPI protocol / driver chain is enabled dynamically, > when appropriate. This is being done in one larger patch, because > ArmVirt.dsc.inc, where AcpiTableDxe is built, is used by all the platform > DSCs. > >

Re: [edk2] [PATCH v3 06/12] EmbeddedPkg: introduce EDKII Platform Has Device Tree GUID

On 24 March 2017 at 22:38, Laszlo Ersek wrote: > The presence of this GUID in the PPI database, and/or in the DXE protocol > database (as dictated by the platform's needs in these firmware phases) > implies that the platform provides the operating system with a Device >

Re: [edk2] [PATCH v3 05/12] ArmPkg: introduce PlatformHasAcpiLib

On 24 March 2017 at 22:38, Laszlo Ersek wrote: > Add the shorter-term library instance outlined in the previous > (MdeModulePkg) patch to ArmPkg, so that we can imbue AcpiTableDxe with a > protocol dependency on EDKII_PLATFORM_HAS_ACPI_GUID. > > Cc: Ard Biesheuvel

Re: [edk2] [PATCH v3 04/12] MdeModulePkg: introduce EDKII Platform Has ACPI GUID

On 24 March 2017 at 22:38, Laszlo Ersek wrote: > The presence of this GUID in the PPI database, and/or in the DXE protocol > database (as dictated by the platform's needs in these firmware phases) > implies that the platform provides the operating system with an ACPI-based >

[edk2] [PATCH v3 01/12] Revert "ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent"

This reverts commit 78c41ff519b187d8979cda7074f007a6323f9acd. We realized that DXE drivers that are independent of AcpiPlatformDxe (that is, independent of QEMU's ACPI generation), such as RamDiskDxe and BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables, at driver dispatch

[edk2] [PATCH v3 03/12] ArmVirtPkg/XenAcpiPlatformDxe: don't cast UINT64 to pointer directly

Because that breaks the (potential) 32-bit build of the driver. Cc: Ard Biesheuvel Cc: Leif Lindholm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Reviewed-by: Ard Biesheuvel

[edk2] [PATCH v3 08/12] ArmVirtPkg: add XenPlatformHasAcpiDtDxe

This driver produces the EDKII Platform Has ACPI and Platform Has Device Tree protocols, exactly matching the current ACPI / DT exposure on Xen, according to ARM vs. AARCH64. At this point it differs from the QEMU driver PlatformHasAcpiDtDxe in that this one always installs the DT. Cc: Ard

[edk2] [PATCH v3 12/12] ArmVirtPkg: remove PURE_ACPI_BOOT_ENABLE and PcdPureAcpiBoot

The build flag and the FeaturePCD have no effect any longer, remove them. Cc: Ard Biesheuvel Cc: Leif Lindholm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Reviewed-by: Ard Biesheuvel

[edk2] [PATCH v3 05/12] ArmPkg: introduce PlatformHasAcpiLib

Add the shorter-term library instance outlined in the previous (MdeModulePkg) patch to ArmPkg, so that we can imbue AcpiTableDxe with a protocol dependency on EDKII_PLATFORM_HAS_ACPI_GUID. Cc: Ard Biesheuvel Cc: Leif Lindholm

[edk2] [PATCH v3 04/12] MdeModulePkg: introduce EDKII Platform Has ACPI GUID

The presence of this GUID in the PPI database, and/or in the DXE protocol database (as dictated by the platform's needs in these firmware phases) implies that the platform provides the operating system with an ACPI-based hardware description. This is not necessarily exclusive with other types of

[edk2] [PATCH v3 09/12] ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL dynamically

In this patch, the ACPI protocol / driver chain is enabled dynamically, when appropriate. This is being done in one larger patch, because ArmVirt.dsc.inc, where AcpiTableDxe is built, is used by all the platform DSCs. No change in behavior should be observable after this patch on any ArmVirtPkg

[edk2] [PATCH v3 11/12] ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI

This will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to the guest. Showing both is never needed (it is actually detrimental to the adoption of standards, such as SBSA / SBBR). * Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe) > Found FwCfg @ 0x9020008/0x902

[edk2] [PATCH v3 10/12] ArmVirtPkg/FdtClientDxe: install DT as sysconfig table in protocol notify

Replace the dependency on PcdPureAcpiBoot with a Platform Has Device Tree notification callback. Move the sysconfig table installation from the entry point function to the callback. Cc: Ard Biesheuvel Cc: Leif Lindholm Contributed-under:

[edk2] [PATCH v3 07/12] ArmVirtPkg: add PlatformHasAcpiDtDxe

This driver produces the EDKII Platform Has ACPI and Platform Has Device Tree protocols, exactly matching the current ACPI / DT exposure on QEMU, according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot. Cc: Ard Biesheuvel Cc: Leif Lindholm

[edk2] [PATCH v3 06/12] EmbeddedPkg: introduce EDKII Platform Has Device Tree GUID

The presence of this GUID in the PPI database, and/or in the DXE protocol database (as dictated by the platform's needs in these firmware phases) implies that the platform provides the operating system with a Device Tree-based hardware description. This is not necessarily exclusive with other

[edk2] [PATCH v3 02/12] Revert "ArmVirtPkg/FdtClientDxe: install DT configuration table at ReadyToBoot"

This reverts commit 18f6d4df9ece8b91b86511bcdd1cf7da478c3627. We realized that DXE drivers that are independent of AcpiPlatformDxe (that is, independent of QEMU's ACPI generation), such as RamDiskDxe and BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables, at driver dispatch

[edk2] [PATCH v3 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI

This is version 3 of the series posted (as v2) previously at . Main changes in this version: * Move gEdkiiPlatformHasAcpiProtocolGuid from ArmPkg to MdeModulePkg, also turning (renaming) the protocol into a generic GUID; update

Re: [edk2] [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined symbols, and MSFT/GCC tool chains.

> -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Friday, March 24, 2017 1:32 PM > To: Felix Poludov > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply > defined symbols, and MSFT/GCC tool chains. > > On

Re: [edk2] [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined symbols, and MSFT/GCC tool chains.

On 24 March 2017 at 12:53, Felix Poludov wrote: > Trying to add GCC support to projects based on MSFT tool chain, I'm keep > stumbling into multiply defined symbol errors reported by GCC linker. > An attempt to understand why the errors are not reported by the Microsoft > linker

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

On 24 March 2017 at 17:10, Laszlo Ersek wrote: > On 03/24/17 08:15, Ard Biesheuvel wrote: >> On 24 March 2017 at 03:44, Zeng, Star wrote: >>> I just think it seems a generic problem. >>> Some platforms may dynamically determine whether ACPI should be

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

On 03/24/17 08:15, Ard Biesheuvel wrote: > On 24 March 2017 at 03:44, Zeng, Star wrote: >> I just think it seems a generic problem. >> Some platforms may dynamically determine whether ACPI should be supported or >> not. >> Some platforms may dynamically determine whether

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

On 03/24/17 04:44, Zeng, Star wrote: > I just think it seems a generic problem. > Some platforms may dynamically determine whether ACPI should be supported or > not. > Some platforms may dynamically determine whether SMBIOS should be supported > or not. > Some platforms may dynamically determine

Re: [edk2] Page Table initialization and update in SMM mode

Jiewen, On 03/22/17 15:14, William Tambe wrote: > Dear all, > > When building OVMF with SMM_REQUIRE: > > - Would you know where in the code base the Page Table set in the Cr3 > register is initialized during boot ? > > - Where does it get updated when a new page needs to be allocated or freed

Re: [edk2] [PATCH] MdeModulePkg/Core/Dxe: Clear SEV mask on MMIO regions

Jiewen, Star, Thanks for the prompt & detailed review. I'll certainly consider your feedback. Leo. > -Original Message- > From: Zeng, Star [mailto:star.z...@intel.com] > Sent: Friday, March 24, 2017 2:57 AM > To: Yao, Jiewen ; Duran, Leo > ;

Re: [edk2] [PATCH v4 0/6] DxeBmDmaLib (BmDmaLib class) library

HI Leo We just did an internal discussion. I will send a proposal to define EDKII_IOMMU_PROTOCOL to abstract DMA operation. (Hope in next week) Thank you Yao Jiewen From: Duran, Leo [mailto:leo.du...@amd.com] Sent: Wednesday, March 15, 2017 5:22 AM To: Ni, Ruiyu ; Yao,

[edk2] [RFC] GLOBAL_REMOVE_IF_UNREFERENCED, multiply defined symbols, and MSFT/GCC tool chains.

Trying to add GCC support to projects based on MSFT tool chain, I'm keep stumbling into multiply defined symbol errors reported by GCC linker. An attempt to understand why the errors are not reported by the Microsoft linker lead me to GLOBAL_REMOVE_IF_UNREFERENCED macro. The purpose of the macro

Re: [edk2] [PATCH 00/14] OvmfPkg: add the Variable PEIM, defragment the UEFI memmap

On 03/24/17 08:38, Jordan Justen wrote: > On 2017-03-22 09:58:24, Laszlo Ersek wrote: >> Jordan, >> >> On 03/16/17 22:22, Laszlo Ersek wrote: >>> On 03/16/17 19:51, Jordan Justen wrote: On 2017-03-14 16:32:32, Laszlo Ersek wrote: > This series implements the ideas discussed in the thread

[edk2] [patch] NetworkPkg: Fix some bugs related to iSCSI keyword configuration.

Add check logic and error message for some keywords validity. show target address in URL format and MAC address correctly. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Zhang Lubo Cc: Ye Ting Cc: Fu Siyuan

Re: [edk2] [PATCH] MdeModulePkg/Core/Dxe: Clear SEV mask on MMIO regions

Jiewen, I like the solution you proposed. :) Thanks, Star -Original Message- From: Yao, Jiewen Sent: Friday, March 24, 2017 3:49 PM To: Zeng, Star ; Leo Duran ; edk2-de...@ml01.01.org Cc: Tian, Feng ; Brijesh Singh

Re: [edk2] [PATCH] MdeModulePkg/Core/Dxe: Clear SEV mask on MMIO regions

Hi Duran I have a little concern about this patch, because we do not introduce any CPU specific thing in DxeCore so far. I think the basic requirement for SEV is to encrypt system memory, but not MMIO. (Please correct me if I am wrong.) If that is the case, I would like to propose another

Re: [edk2] [PATCH] MdeModulePkg/Core/Dxe: Clear SEV mask on MMIO regions

I have comments below. 1. Why need to call ConvertEncryptionOnAddressRange() at GCD_FREE_MEMORY_OPERATION case? GCD_FREE_MEMORY_OPERATION does not change the Entry->GcdMemoryType. 2. I think it is better to use if (Entry->GcdMemoryType == EfiGcdMemoryTypeMemoryMappedIo) instead of if

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

On 24 March 2017 at 03:44, Zeng, Star wrote: > I just think it seems a generic problem. > Some platforms may dynamically determine whether ACPI should be supported or > not. > Some platforms may dynamically determine whether SMBIOS should be supported > or not. > Some

Re: [edk2] Closing events and releasing resources in notify function

> On Mar 24, 2017, at 12:07 AM, Arka Sharma wrote: > > Thanks Andrew for your reply. In this case I am creating the event > with CreateEvent() and not with CreateEventEx(). I am attempting to > free the Context inside the notify function which will be called after > Event

Re: [edk2] Closing events and releasing resources in notify function

Thanks Andrew for your reply. In this case I am creating the event with CreateEvent() and not with CreateEventEx(). I am attempting to free the Context inside the notify function which will be called after Event is signaled, and Context is only accessed before CreateEvent() and inside the

[edk2] [Patch] MdePkg/UefiDevicePathLib: Refine the DevPathFromTextiSCSI protocol parsing

For current iSCSI protocol parsing, UINT16 truncation may be happened. Since the Spec already have declaimed that 0 is TCP Protocol and 1+ is reserved, the parsing can be refined as below: if (StrCmp (ProtocolStr, L"TCP") == 0) { ISCSIDevPath->NetworkProtocol = 0; } else { // //

Re: [edk2] Closing events and releasing resources in notify function

> On Mar 23, 2017, at 11:22 PM, Arka Sharma wrote: > > Hi, > > Is it ok to close the event and release the resource allocated to be > sent as context inside the notify function. May be something like this > > VOID > EFIAPI > NotifyRoutine ( > EFI_EVENT Event, >

[edk2] Closing events and releasing resources in notify function

Hi, Is it ok to close the event and release the resource allocated to be sent as context inside the notify function. May be something like this VOID EFIAPI NotifyRoutine ( EFI_EVENT Event, VOID *Context ) { // // Perform intended task // FreePool (Context);

[edk2] [Patch] NetworkPkg/DnsDxe: Fix zero StationIp configuration failure of DNSv6

According UEFI Spec, set to zero StationIp means to let the underlying IPv6 driver choose a source address. But currently, DNSv6 always return EFI_NO_MAPPING. The issue is caused by below bugs in DnsDxe: * Incorrect TPL(TPL_CALLBACK) usage during UDP configuration. * Failed to create the timer