Re: [edk2-devel] [edk2-platforms][PATCH 1/3] AmpereAltraPkg: Remove PCIe "DevMapModeAuto" case in retrieving Devmap mode

[Tinh Nguyen via groups.io]

Reviewed-by: Tinh Nguyen 

On 11/05/2023 14:51, Minh Nguyen wrote:

Because PCIe Auto bifurcation feature doesn't depend on the default
Devmap mode so that "DevMapModeAuto" is unnecessary in retrieving
the PCIe Devmap default mode.

Signed-off-by: Minh Nguyen 
---
  Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/RootComplexNVParam.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/RootComplexNVParam.c 
b/Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/RootComplexNVParam.c
index a8e23015b605..199929bfdb24 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/RootComplexNVParam.c
+++ b/Silicon/Ampere/AmpereAltraPkg/Drivers/PcieInitPei/RootComplexNVParam.c
@@ -160,7 +160,7 @@ GetDefaultDevMap (
UINT8StartIndex;
DEV_MAP_MODE DevMapMode;
  
-  DevMapMode = MaxDevMapMode;

+  DevMapMode = DevMapMode4;
StartIndex = IsGetDevMapLow ? PcieController0 : PcieController4;
  
while (DevMapMode >= DevMapMode1)



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105103): https://edk2.groups.io/g/devel/message/105103
Mute This Topic: https://groups.io/mt/98831763/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 2/3] AmpereAltraPkg: Fix PCIe link training sequence

[Tinh Nguyen via groups.io]

Reviewed-by: Tinh Nguyen 


@Leif, @Ard, Please help us to merge this series

Thanks,

- Tinh

On 11/05/2023 14:51, Minh Nguyen wrote:

Currently, the implementation starts link training and put device
out-of-reset right away. This make LinkStat and BlockEventStat registers
indicate that link is not up yet (LinkStat: 0x300 and BlockEventStat: 0x0).
This fix will start link training after putting device out-of-reset.
The values of LinkStat and BlockEventStat registers after this fix are
respectively 0x1103 and 0x1 (Link is up).

Signed-off-by: Minh Nguyen 
---
  Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c 
b/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
index f7c8defc1906..d797442d9fbc 100644
--- a/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
+++ b/Silicon/Ampere/AmpereAltraPkg/Library/Ac01PcieLib/PcieCore.c
@@ -1177,12 +1177,12 @@ Ac01PcieCoreSetupRC (
  // Assert PERST low to reset endpoint
  BoardPcieAssertPerst (RootComplex, PcieIndex, FALSE);
  
+// Complete the PERST pulse

+BoardPcieAssertPerst (RootComplex, PcieIndex, TRUE);
+
  // Start link training
  StartLinkTraining (RootComplex, PcieIndex, TRUE);
  
-// Complete the PERST pulse

-BoardPcieAssertPerst (RootComplex, PcieIndex, TRUE);
-
  // Lock programming of config space
  EnableDbiAccess  (RootComplex, PcieIndex, FALSE);
  



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105104): https://edk2.groups.io/g/devel/message/105104
Mute This Topic: https://groups.io/mt/98831764/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-stable202305] ArmPkg/ArmMmuLib: Add missing ISB after page table update

[Ard Biesheuvel]

Any objections to this? If not, I will push it later today. Thanks.



On Sat, 20 May 2023 at 11:20, Ard Biesheuvel  wrote:
>
> The helper that updates live page table entries writes a zero entry,
> invalidates the covered address range from the TLBs, and finally writes
> the actual entry. This ensures that no TLB conflicts can occur.
>
> Writing the final entry needs to complete before any translations can be
> performed, as otherwise, the zero entry, which describes an invalid
> translation, may be observed by the page table walker, resulting in a
> translation fault. For this reason, the final write is followed by a DSB
> barrier instruction.
>
> However, this barrier will not stall the pipeline, and instruction
> fetches may still hit this invalid translation, as has been observed and
> reported by Oliver. To ensure that the new translation is fully active
> before returning from this helper, we have to insert an ISB barrier as
> well.
>
> Cc: Liming Gao 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Reported-by: Oliver Steffen 
> Tested-by: Oliver Steffen 
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S 
> b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> index 887439bc042f0f16..1f0d8057926933d7 100644
> --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> @@ -65,6 +65,7 @@
>// write updated entry
>str   x1, [x0]
>dsb   nshst
> +  isb
>
>  .L2_\@:
>.endm
> --
> 2.39.2
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105105): https://edk2.groups.io/g/devel/message/105105
Mute This Topic: https://groups.io/mt/99027974/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 0/2] AMD/AmdMinBoardPkg: ReportFvLib library and

[Abdul Lateef Attar via groups.io]

Implements ReportFvLibLirary.
Implements PciHotPlugInit protocol.

Cc: Abner Chang 

Abdul Lateef Attar (2):
  AMD/AmdMinBoardPkg: Implements PCI hotplug init protocol
  AMD/AmdMinBoardkPkg: Implements PeiReportFvLib Library

 .../AMD/AmdMinBoardPkg/AmdMinBoardPkg.dec |  24 ++
 .../AMD/AmdMinBoardPkg/AmdMinBoardPkg.dsc |  16 +-
 .../Library/PeiReportFvLib/PeiReportFvLib.inf |  57 +++
 .../PciHotPlug/PciHotPlugInit.inf |  39 +++
 .../Library/PeiReportFvLib/PeiReportFvLib.c   | 239 +
 .../PciHotPlug/PciHotPlugInit.c   | 331 ++
 6 files changed, 705 insertions(+), 1 deletion(-)
 create mode 100644 
Platform/AMD/AmdMinBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.inf
 create mode 100755 Platform/AMD/AmdMinBoardPkg/PciHotPlug/PciHotPlugInit.inf
 create mode 100644 
Platform/AMD/AmdMinBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.c
 create mode 100755 Platform/AMD/AmdMinBoardPkg/PciHotPlug/PciHotPlugInit.c

-- 
2.25.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105106): https://edk2.groups.io/g/devel/message/105106
Mute This Topic: https://groups.io/mt/99061259/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 1/2] AMD/AmdMinBoardPkg: Implements PCI hotplug init protocol

[Abdul Lateef Attar via groups.io]

From: Abdul Lateef Attar 

Implements PCI hotplug init protocol.
Adds resources padding based on PCD values.

Cc: Abner Chang 

Signed-off-by: Abdul Lateef Attar 
---
 .../AMD/AmdMinBoardPkg/AmdMinBoardPkg.dec |  16 +
 .../AMD/AmdMinBoardPkg/AmdMinBoardPkg.dsc |  14 +-
 .../PciHotPlug/PciHotPlugInit.inf |  39 +++
 .../PciHotPlug/PciHotPlugInit.c   | 331 ++
 4 files changed, 399 insertions(+), 1 deletion(-)
 create mode 100755 Platform/AMD/AmdMinBoardPkg/PciHotPlug/PciHotPlugInit.inf
 create mode 100755 Platform/AMD/AmdMinBoardPkg/PciHotPlug/PciHotPlugInit.c

diff --git a/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dec 
b/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dec
index e37b02c4cf5a..65ba08545021 100644
--- a/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dec
+++ b/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dec
@@ -17,3 +17,19 @@ [Defines]
   PACKAGE_GUID   = 44F9D761-9ECB-43DD-A5AC-177E5048701B
   PACKAGE_VERSION= 0.1
 
+[Guids]
+  gAmdMinBoardPkgTokenSpaceGuid  = {0xd4d23d79, 0x73bf, 0x460a, {0xa1, 0xc7, 
0x85, 0xa3, 0xca, 0x71, 0xb9, 0x4c}}
+
+[PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
+  #
+  # PCI HotPlug Resource Padding
+  #
+  # PCI bus padding, number of bus to reserve, default 2 bus
+  gAmdMinBoardPkgTokenSpaceGuid.PcdPciHotPlugResourcePadBus|2|UINT8|0x1003
+  # IO Resource padding in bytes, default 4KB
+  
gAmdMinBoardPkgTokenSpaceGuid.PcdPciHotPlugResourcePadIo|0x1000|UINT32|0x1000
+  # Non-PreFetch Memory padding in bytes, default 1MB
+  
gAmdMinBoardPkgTokenSpaceGuid.PcdPciHotPlugResourcePadMem|0x0010|UINT32|0x1002
+  # PreFetch Memory padding in bytes, default 2MB
+  
gAmdMinBoardPkgTokenSpaceGuid.PcdPciHotPlugResourcePadPMem|0x0020|UINT32|0x1001
+
diff --git a/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dsc 
b/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dsc
index 273cd74f7842..1a8407250c56 100644
--- a/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dsc
+++ b/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dsc
@@ -9,7 +9,7 @@
 
 [Defines]
   DSC_SPECIFICATION   = 1.30
-  PLATFORM_GUID   = 88F8A9AE-2FA0-4D58-A6F9-05F635C05F4E
+  PLATFORM_GUID   = 939B559B-269B-4B8F-9637-44DF6575C1E2
   PLATFORM_NAME   = AmdMinBoardPkg
   PLATFORM_VERSION= 0.1
   OUTPUT_DIRECTORY= Build/$(PLATFORM_NAME)
@@ -25,6 +25,16 @@ [Packages]
 [LibraryClasses]
   SpcrDeviceLib|AmdMinBoardPkg/Library/SpcrDeviceLib/SpcrDeviceLib.inf
 
+[LibraryClasses.common]
+  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
+  BaseMemoryLib|MdePkg/Library/BaseMemoryLibRepStr/BaseMemoryLibRepStr.inf
+  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
+  
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
+  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+  
RegisterFilterLib|MdePkg/Library/RegisterFilterLibNull/RegisterFilterLibNull.inf
+  
UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
+  
UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
+
 [LibraryClasses.common.PEIM]
   SetCacheMtrrLib|AmdMinBoardPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.inf
 
@@ -34,3 +44,5 @@ [Components]
 [Components.IA32]
   AmdMinBoardPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.inf
 
+[Components.X64]
+  AmdMinBoardPkg/PciHotPlug/PciHotPlugInit.inf
diff --git a/Platform/AMD/AmdMinBoardPkg/PciHotPlug/PciHotPlugInit.inf 
b/Platform/AMD/AmdMinBoardPkg/PciHotPlug/PciHotPlugInit.inf
new file mode 100755
index ..44564df38718
--- /dev/null
+++ b/Platform/AMD/AmdMinBoardPkg/PciHotPlug/PciHotPlugInit.inf
@@ -0,0 +1,39 @@
+## @file
+# This driver implements EFI_PCI_HOT_PLUG_INIT_PROTOCOL.
+# Adds resource padding information, for PCIe hotplug purposes.
+#
+# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved
+# SPDX-License-Identifier: BSD-2-Clause-Patent ##
+
+[Defines]
+  INF_VERSION= 1.29
+  BASE_NAME  = PciHotPlugInit
+  FILE_GUID  = 85F78A6D-6438-4BCC-B796-759A48D00C72
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 0.1
+  ENTRY_POINT= PciHotPlugInitialize
+
+[Sources]
+  PciHotPlugInit.c
+
+[Packages]
+  AmdMinBoardPkg/AmdMinBoardPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  MemoryAllocationLib
+  UefiBootServicesTableLib
+  UefiDriverEntryPoint
+
+[Protocols]
+  gEfiPciHotPlugInitProtocolGuid
+
+[Pcd]
+  gAmdMinBoardPkgTokenSpaceGuid.PcdPciHotPlugResourcePadBus
+  gAmdMinBoardPkgTokenSpaceGuid.PcdPciHotPlugResourcePadIo
+  gAmdMinBoardPkgTokenSpaceGuid.PcdPciHotPlugResourcePadMem
+  gAmdMinBoardPkgTokenSpaceGuid.PcdPciHotPlugResourcePadPMem
+
+[Depex]
+  TRUE
diff --git a/Platform/AMD/AmdMinBoardPkg/PciHotPlug/PciHotPlugInit.c 
b/Platform/AMD/AmdMinBoardPkg/PciHotPlug

[edk2-devel] [PATCH v2 2/2] AMD/AmdMinBoardkPkg: Implements PeiReportFvLib Library

[Abdul Lateef Attar via groups.io]

Customize PeiReportFvLib library for AMD platforms by
adding below changes.
  Installs Advanced Security FV.
  Adds facility to install FV above 4GB address space.

Cc: Abner Chang 

Signed-off-by: Abdul Lateef Attar 
---
 .../AMD/AmdMinBoardPkg/AmdMinBoardPkg.dec |   8 +
 .../AMD/AmdMinBoardPkg/AmdMinBoardPkg.dsc |   2 +
 .../Library/PeiReportFvLib/PeiReportFvLib.inf |  57 +
 .../Library/PeiReportFvLib/PeiReportFvLib.c   | 239 ++
 4 files changed, 306 insertions(+)
 create mode 100644 
Platform/AMD/AmdMinBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.inf
 create mode 100644 
Platform/AMD/AmdMinBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.c

diff --git a/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dec 
b/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dec
index 65ba08545021..03d1d77c34eb 100644
--- a/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dec
+++ b/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dec
@@ -33,3 +33,11 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
PcdsDynamicEx]
   # PreFetch Memory padding in bytes, default 2MB
   
gAmdMinBoardPkgTokenSpaceGuid.PcdPciHotPlugResourcePadPMem|0x0020|UINT32|0x1001
 
+  # PCDs to support loading of FV above 4GB address space
+  gAmdMinBoardPkgTokenSpaceGuid.PcdAmdFlashFvAdvancedBase
|0x|UINT64|0x1004
+  gAmdMinBoardPkgTokenSpaceGuid.PcdAmdFlashFvOsBootBase  
|0x|UINT64|0x1005
+  gAmdMinBoardPkgTokenSpaceGuid.PcdAmdFlashFvUefiBootBase
|0x|UINT64|0x1006
+  gAmdMinBoardPkgTokenSpaceGuid.PcdAmdFlashFvAdvancedSecurityBase
|0x|UINT64|0x1007
+  gAmdMinBoardPkgTokenSpaceGuid.PcdAmdFlashFvAdvancedSecuritySize
|0x|UINT32|0x1008
+  gAmdMinBoardPkgTokenSpaceGuid.PcdAmdFlashFvAdvancedSecurityOffset  
|0x|UINT32|0x1009
+
diff --git a/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dsc 
b/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dsc
index 1a8407250c56..be33089a45ef 100644
--- a/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dsc
+++ b/Platform/AMD/AmdMinBoardPkg/AmdMinBoardPkg.dsc
@@ -24,6 +24,7 @@ [Packages]
 
 [LibraryClasses]
   SpcrDeviceLib|AmdMinBoardPkg/Library/SpcrDeviceLib/SpcrDeviceLib.inf
+  ReportFvLib|AmdMinBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.inf
 
 [LibraryClasses.common]
   BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
@@ -43,6 +44,7 @@ [Components]
 
 [Components.IA32]
   AmdMinBoardPkg/Library/SetCacheMtrrLib/SetCacheMtrrLib.inf
+  AmdMinBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.inf
 
 [Components.X64]
   AmdMinBoardPkg/PciHotPlug/PciHotPlugInit.inf
diff --git 
a/Platform/AMD/AmdMinBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.inf 
b/Platform/AMD/AmdMinBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.inf
new file mode 100644
index ..23ee503c42be
--- /dev/null
+++ b/Platform/AMD/AmdMinBoardPkg/Library/PeiReportFvLib/PeiReportFvLib.inf
@@ -0,0 +1,57 @@
+### @file
+# Component information file for the Report Firmware Volume (FV) library.
+#
+# Copyright (c) 2018 - 2020, Intel Corporation. All rights reserved.
+# Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+###
+
+[Defines]
+  INF_VERSION= 1.29
+  BASE_NAME  = PeiReportFvLib
+  FILE_GUID  = 3C207C28-DC43-4A3A-B572-6794C77AB519
+  VERSION_STRING = 1.0
+  MODULE_TYPE= PEIM
+  LIBRARY_CLASS  = ReportFvLib
+
+[LibraryClasses]
+  BaseMemoryLib
+  DebugLib
+  HobLib
+  PeiServicesLib
+
+[Packages]
+  AmdMinBoardPkg/AmdMinBoardPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  MinPlatformPkg/MinPlatformPkg.dec
+
+[Sources]
+  PeiReportFvLib.c
+
+[Pcd]
+  gAmdMinBoardPkgTokenSpaceGuid.PcdAmdFlashFvAdvancedBase ## CONSUMES
+  gAmdMinBoardPkgTokenSpaceGuid.PcdAmdFlashFvAdvancedSecurityBase ## CONSUMES
+  gAmdMinBoardPkgTokenSpaceGuid.PcdAmdFlashFvAdvancedSecuritySize ## CONSUMES
+  gAmdMinBoardPkgTokenSpaceGuid.PcdAmdFlashFvOsBootBase   ## CONSUMES
+  gAmdMinBoardPkgTokenSpaceGuid.PcdAmdFlashFvUefiBootBase ## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdBootStage  ## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdFlashAreaBaseAddress   ## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdFlashAreaSize  ## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdFlashFvAdvancedBase## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdFlashFvAdvancedPreMemoryBase   ## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdFlashFvAdvancedPreMemorySize   ## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdFlashFvAdvancedSize## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdFlashFvFspTBase## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdFlashFvFspTSize## CONSUMES
+  gMinPlatformPkgTokenSpaceGuid.PcdFlashFvOsBootBase  ## CONSUMES
+  gM

Re: [edk2-devel] [PATCH 0/3] OvmfPkg: gigabyte page tweaks

[Gerd Hoffmann]

On Thu, May 18, 2023 at 12:16:21AM +0100, Pedro Falcato wrote:
> On Wed, May 17, 2023 at 11:24 AM Gerd Hoffmann  wrote:

> The Intel SDM and AMD manuals both mention possible bad side effects
> for having large pages (2MB/4MB/1GB) spanning multiple MTRRs.

qemu takes care to use gigabyte-alignment for guest RAM for performance
reasons.  Unless you are explicitly creating something unusual the
memory layout below 4G is 2G RAM + 2G MMIO (q35 machine type) or 3G RAM
+ 1G MMIO (pc machine type).

edk2 creates mtrr uncachable entries for the mmio regions (both 32bit
and 64bit window).  On q35 it looks like this:

  reg00: base=0x08000 ( 2048MB), size= 2048MB, count=1: uncachable
  reg01: base=0x70 (458752MB), size=65536MB, count=1: uncachable

Both are gigabyte-aligned and are a multiple of gigabytes in size, so
you simply can't create gigabyte page table entries crossing mtrr entry
borders.

That's relatively recent change though, q35 used to be different, see
commit e4b3fd905a17 ("OvmfPkg/PlatformInitLib: simplify mtrr setup")

> While I don't expect my comment to be a blocker (particularly as other
> OVMF platforms are already using them), I think it's probably a good
> idea to let you know.

Yes, thanks, sure good to know.  But I don't expect that being a
problem.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105109): https://edk2.groups.io/g/devel/message/105109
Mute This Topic: https://groups.io/mt/98944976/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/3] OvmfPkg/PlatformInitLib: check PcdUse1GPageTable

[Ard Biesheuvel]

On Wed, 17 May 2023 at 12:24, Gerd Hoffmann  wrote:
>
> If PcdUse1GPageTable is not enabled restrict the physical address space
> used to 1TB, to limit the amount of memory needed for identity mapping
> page tables.
>
> The same already happens in case the processor has no support for
> gigabyte pages.
>

Apologies for the noob question, but does this mean EDK2 maps the
entire address space 1:1, not just the region that as any DRAM in it?


> Signed-off-by: Gerd Hoffmann 
> ---
>  OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf | 1 +
>  OvmfPkg/Library/PlatformInitLib/MemDetect.c | 5 +
>  2 files changed, 6 insertions(+)
>
> diff --git a/OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf 
> b/OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf
> index 86a82ad3e084..5a79d95b689c 100644
> --- a/OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf
> +++ b/OvmfPkg/Library/PlatformInitLib/PlatformInitLib.inf
> @@ -58,6 +58,7 @@ [LibraryClasses.X64]
>
>  [Pcd]
>gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
>
>  [FixedPcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfWorkAreaBase
> diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
> b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> index acf90b4e93fd..1102b00ecbf0 100644
> --- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> +++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
> @@ -663,6 +663,11 @@ PlatformAddressWidthFromCpuid (
>PhysBits = 40;
>  }
>
> +if (!FixedPcdGetBool (PcdUse1GPageTable) && (PhysBits > 40)) {
> +  DEBUG ((DEBUG_INFO, "%a: limit PhysBits to 40 (PcdUse1GPageTable is 
> false)\n", __func__));
> +  PhysBits = 40;
> +}
> +
>  PlatformInfoHob->PhysMemAddressWidth = PhysBits;
>  PlatformInfoHob->FirstNonAddress = LShiftU64 (1, 
> PlatformInfoHob->PhysMemAddressWidth);
>}
> --
> 2.40.1
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105110): https://edk2.groups.io/g/devel/message/105110
Mute This Topic: https://groups.io/mt/98944978/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-stable202305] ArmPkg/ArmMmuLib: Add missing ISB after page table update

[Leif Lindholm]

On Sat, May 20, 2023 at 11:19:58 +0200, Ard Biesheuvel wrote:
> The helper that updates live page table entries writes a zero entry,
> invalidates the covered address range from the TLBs, and finally writes
> the actual entry. This ensures that no TLB conflicts can occur.
> 
> Writing the final entry needs to complete before any translations can be
> performed, as otherwise, the zero entry, which describes an invalid
> translation, may be observed by the page table walker, resulting in a
> translation fault. For this reason, the final write is followed by a DSB
> barrier instruction.
> 
> However, this barrier will not stall the pipeline, and instruction
> fetches may still hit this invalid translation, as has been observed and
> reported by Oliver. To ensure that the new translation is fully active
> before returning from this helper, we have to insert an ISB barrier as
> well.
> 
> Cc: Liming Gao 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Reported-by: Oliver Steffen 
> Tested-by: Oliver Steffen 
> Signed-off-by: Ard Biesheuvel 

Reviewed-by: Leif Lindholm 

We need this in the stable tag.

Note: the isb instruction forces the synchronization of certain
architectural events. It has no other effects. I.e., any issues
exposed by this addition would already have been present before it.

As such, I would suggest this addition need *not* affect the stable
tag schedule.

/
Leif

> ---
>  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S 
> b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> index 887439bc042f0f16..1f0d8057926933d7 100644
> --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> @@ -65,6 +65,7 @@
>// write updated entry
>str   x1, [x0]
>dsb   nshst
> +  isb
>  
>  .L2_\@:
>.endm
> -- 
> 2.39.2
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105111): https://edk2.groups.io/g/devel/message/105111
Mute This Topic: https://groups.io/mt/99027974/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 3/4] OvmfPkg/PlatformInitLib: dynamic mmio window size

[Gerd Hoffmann]

> The errors for the virtio devices are:
> >  virtio_scsi virtio1: virtio: device uses modern interface but does not 
> > have VIRTIO_F_VERSION_1   
> >  virtio_scsi: probe of virtio1 failed with error -22
> >  virtio_net virtio2: virtio: device uses modern interface but does not have 
> > VIRTIO_F_VERSION_1
> >  virtio_net: probe of virtio2 failed with error -22

I guess something goes wrong with accessing the mmio pci bars.

Seems to be a linux kernel bug in 4.15, when installing the hwe
kernel (5.4) it works fine for me.

> In the kern.log, I didn't really see any interesting differences, except
> for the errors above. The addresses are different and there is now a
> 64-bit bridge window, but I guess that's expected.
> 
> > +  pci :00:1e.0:   bridge window [mem 0x7000-0x700f 
> > 64bit pref]

Yes.

> Not sure if this is interesting either, but part of the diff between the
> lspci outputs (first with the call, second without the call):
> 
> > ***
> > *** 75,88 
> >   00:05.0 SCSI storage controller: Red Hat, Inc Virtio SCSI
> > Subsystem: Red Hat, Inc Virtio SCSI
> > Physical Slot: 5
> > !   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> > Stepping- SERR- FastB2B- DisINTx+

INTx enabled.

> > !   Capabilities: [98] MSI-X: Enable+ Count=7 Masked-

MSI-X enabled.

That probably comes from the driver exiting early (and not configuring
interrupts).

The patch below fixes it for me.  Can you confirm this?

take care,
  Gerd

>From 05fdf93b17decc42dde2ba89e935616eceb705c4 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann 
Date: Mon, 22 May 2023 13:04:35 +0200
Subject: [PATCH 1/1] [testing] older linux kernels seem to have problems with
 phys-bits > 46

---
 OvmfPkg/Library/PlatformInitLib/MemDetect.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c 
b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index acf90b4e93fd..0482d8906d5c 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -646,16 +646,19 @@ PlatformAddressWidthFromCpuid (
 ));
 
   if (Valid) {
-if (PhysBits > 47) {
+if (PhysBits > 46) {
   /*
* Avoid 5-level paging altogether for now, which limits
* PhysBits to 48.  Also avoid using address bit 48, due to sign
* extension we can't identity-map these addresses (and lots of
* places in edk2 assume we have everything identity-mapped).
* So the actual limit is 47.
+   *
+   * Also some older linux kernels apparently have problems handling
+   * phys-bits > 46 correctly, so use that as limit.
*/
-  DEBUG ((DEBUG_INFO, "%a: limit PhysBits to 47 (avoid 5-level paging)\n", 
__func__));
-  PhysBits = 47;
+  DEBUG ((DEBUG_INFO, "%a: limit PhysBits to 46 (avoid 5-level paging)\n", 
__func__));
+  PhysBits = 46;
 }
 
 if (!Page1GSupport && (PhysBits > 40)) {
-- 
2.40.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105112): https://edk2.groups.io/g/devel/message/105112
Mute This Topic: https://groups.io/mt/94113626/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/3] OvmfPkg/PlatformInitLib: check PcdUse1GPageTable

[Gerd Hoffmann]

On Mon, May 22, 2023 at 12:37:51PM +0200, Ard Biesheuvel wrote:
> On Wed, 17 May 2023 at 12:24, Gerd Hoffmann  wrote:
> >
> > If PcdUse1GPageTable is not enabled restrict the physical address space
> > used to 1TB, to limit the amount of memory needed for identity mapping
> > page tables.
> >
> > The same already happens in case the processor has no support for
> > gigabyte pages.
> >
> 
> Apologies for the noob question, but does this mean EDK2 maps the
> entire address space 1:1, not just the region that as any DRAM in it?

I just saw memory usage and boot time go up.  Didn't check whenever that
was just the 64-bit mmio area (which recent ovmf scales up with the
available address space) or all address space.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105113): https://edk2.groups.io/g/devel/message/105113
Mute This Topic: https://groups.io/mt/98944978/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] IntelFsp2WrapperPkg: Fix ASSERT when FSP-S/M use FFS3

[Ashraf Ali S]

Reviewed-by: S, Ashraf Ali 

-Original Message-
From: devel@edk2.groups.io  On Behalf Of Tan, Ming
Sent: Monday, May 22, 2023 11:43 AM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Duggapu, Chinni B 

Subject: [edk2-devel] [PATCH] IntelFsp2WrapperPkg: Fix ASSERT when FSP-S/M use 
FFS3

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4458

Original code call PeiServicesInstallFvInfoPpi() with NULL for the FvFormat 
parameter, then PeiServicesInstallFvInfoPpi() will assume it use FFS2, then 
ASSERT if FSP-S/M use FFS3.
Now set the FvFormat to the info got from FvHeader.

Cc: Chasel Chiu 
Cc: Duggapu Chinni B 
Signed-off-by: Ming Tan 
---
 IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c | 2 +-  
IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
index ea206a7960..ba0c742fea 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
@@ -217,7 +217,7 @@ FspmWrapperInit (
 ASSERT_EFI_ERROR (Status);  PeiServicesInstallFvInfoPpi (-  NULL,+ 
 &((EFI_FIRMWARE_VOLUME_HEADER *)(UINTN)PcdGet32 
(PcdFspmBaseAddress))->FileSystemGuid,   (VOID *)(UINTN)PcdGet32 
(PcdFspmBaseAddress),   (UINT32)((EFI_FIRMWARE_VOLUME_HEADER 
*)(UINTN)PcdGet32 (PcdFspmBaseAddress))->FvLength,   NULL,diff --git 
a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
index 091ddb697a..08fe0fdb7e 100644
--- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
@@ -438,7 +438,7 @@ FspsWrapperInitDispatchMode (
   // FSP-S Wrapper running in Dispatch mode and reports FSP-S FV to PEI 
dispatcher.   //   PeiServicesInstallFvInfoPpi (-NULL,+
&((EFI_FIRMWARE_VOLUME_HEADER *)(UINTN)PcdGet32 
(PcdFspsBaseAddress))->FileSystemGuid, (VOID *)(UINTN)PcdGet32 
(PcdFspsBaseAddress), (UINT32)((EFI_FIRMWARE_VOLUME_HEADER 
*)(UINTN)PcdGet32 (PcdFspsBaseAddress))->FvLength, NULL,-- 
2.31.1.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105101): https://edk2.groups.io/g/devel/message/105101
Mute This Topic: https://groups.io/mt/99059532/6226280
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [ashraf.al...@intel.com] 
-=-=-=-=-=-=




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105114): https://edk2.groups.io/g/devel/message/105114
Mute This Topic: https://groups.io/mt/99059532/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] managing memory attributes in PEI

[Ard Biesheuvel]

Hello all,

(OVMF specific questions below - please keep reading)

As a follow-up to the discussion we had last week regarding DXE core,
I'd like to raise the issue of managing memory permissions in PEI,
including the mapping attributes of the code and data regions of DXE
core itself.

This is about good hygiene in general, but on arm64 in particular,
limiting execution permissions to memory regions that are mapped
read-only allows the MMU to be enabled in WXN mode, where all writable
regions are non-executable by default.

I have implemented a proof-of-concept of this for ArmVirtQemu and
Raspberry Pi 4 (the former using PEI and the latter PEI-less), and
this seems quite feasible in practice, but there are a few issues that
I have identified:

- PEI shadowing is currently disabled entirely - this is actually an
advantage for the [virtual] platform in question, given that shadowing
is more work for no benefit, but it is something that needs to be
addressed in the general case;
- no generic method exists to manage page table permissions.

So what I would like to propose (and what I intend to prototype) is a
PPI that abstracts this capability, and which can be used by the PEI
image loader as well as the DxeIpl to manage read-only and non-exec
permissions. Most PEIMs only have a code region anyway, so hopefully
there is some room for optimization where not all PEIMs need 4k
alignment.

That leaves one big issue, and this is related to OVMF's use of IA32
PEI with X64 DXE. This complicates the DxeIpl substantially already,
but would make this effort rather tricky as well.

So my questions are:
- do we need to retain mixed IA32 / X64 support, and if so, why? (I
think it is related to SMM emulation but I need someone to confirm
this)
- if we need to retain it, could we run PEI in long mode but with
32-bit compatibility enabled, so that we don't need two or three
incompatible sets of page tables?

In the latter case, the PPI in question would carry the same logic for
IA32 and X64 builds, and create 4-level page tables with the code
still being 32-bit.

Once we clear this up, I'm happy to look into extending my prototype
to x86 as well.

Thanks,
Ard.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105115): https://edk2.groups.io/g/devel/message/105115
Mute This Topic: https://groups.io/mt/99062463/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 0/1] PcAtChipsetPkg: RTC Runtime unable to get correct IO port by PCD

[Guo, Gua]

From: Gua Guo 

PR: https://github.com/tianocore/edk2/pull/4416

V2: Add more dynamic PCD for runtime service support instead of taking for 
FixedAtBuild case

V1: After https://bugzilla.tianocore.org/show_bug.cgi?id=4193
RTC Runtime Services unable to get correct RTC time.
Solution: Cache RTC data, update RTC driver not to use PcdGet after driver init.

Gua Guo (1):
  PcAtChipsetPkg: RTC Runtime unable to get correct IO port by PCD

 .../PcatRealTimeClockRuntimeDxe/PcRtc.c   | 38 ++-
 .../PcatRealTimeClockRuntimeDxe/PcRtcEntry.c  | 16 +++-
 2 files changed, 35 insertions(+), 19 deletions(-)

--
2.39.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105116): https://edk2.groups.io/g/devel/message/105116
Mute This Topic: https://groups.io/mt/99063018/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 1/1] PcAtChipsetPkg: RTC Runtime unable to get correct IO port by PCD

[Guo, Gua]

From: Gua Guo 

RTC runtime is unable to get dynamic PCD value after booting to
OS using runtime services.

Resolution: Cache the dynamic PCD value in RTC driver entry point

Cc: Ray Ni 
Cc: Michael D Kinney 
Signed-off-by: Gua Guo 
---
 .../PcatRealTimeClockRuntimeDxe/PcRtc.c   | 38 ++-
 .../PcatRealTimeClockRuntimeDxe/PcRtcEntry.c  | 16 +++-
 2 files changed, 35 insertions(+), 19 deletions(-)

diff --git a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c 
b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c
index d8b9fa8376..795ec950a8 100644
--- a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c
+++ b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c
@@ -11,9 +11,13 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 
 #include "PcRtc.h"
 
-extern UINTN  mRtcIndexRegister;
-extern UINTN  mRtcTargetRegister;
-
+extern UINTN   mRtcIndexRegister;
+extern UINTN   mRtcTargetRegister;
+extern UINTN   mRtcIndexRegisterIo;
+extern UINTN   mRtcTargetRegisterIo;
+extern UINT16  mRtcDefaultYear;
+extern UINT16  mMinimalValidYear;
+extern UINT16  mMaximalValidYear;
 //
 // Days of month.
 //
@@ -72,10 +76,10 @@ IoRtcRead (
   )
 {
   IoWrite8 (
-PcdGet8 (PcdRtcIndexRegister),
-(UINT8)(Address | (UINT8)(IoRead8 (PcdGet8 (PcdRtcIndexRegister)) & 0x80))
+mRtcIndexRegisterIo,
+(UINT8)(Address | (UINT8)(IoRead8 (mRtcIndexRegisterIo) & 0x80))
 );
-  return IoRead8 (PcdGet8 (PcdRtcTargetRegister));
+  return IoRead8 (mRtcTargetRegisterIo);
 }
 
 /**
@@ -94,10 +98,10 @@ IoRtcWrite (
   )
 {
   IoWrite8 (
-PcdGet8 (PcdRtcIndexRegister),
-(UINT8)(Address | (UINT8)(IoRead8 (PcdGet8 (PcdRtcIndexRegister)) & 0x80))
+mRtcIndexRegisterIo,
+(UINT8)(Address | (UINT8)(IoRead8 (mRtcIndexRegisterIo) & 0x80))
 );
-  IoWrite8 (PcdGet8 (PcdRtcTargetRegister), Data);
+  IoWrite8 (mRtcTargetRegisterIo, Data);
 }
 
 /**
@@ -317,8 +321,8 @@ PcRtcInit (
 Time.Hour   = RTC_INIT_HOUR;
 Time.Day= RTC_INIT_DAY;
 Time.Month  = RTC_INIT_MONTH;
-Time.Year   = MAX (PcdGet16 (PcdRtcDefaultYear), PcdGet16 
(PcdMinimalValidYear));
-Time.Year   = MIN (Time.Year, PcdGet16 (PcdMaximalValidYear));
+Time.Year   = MAX (mRtcDefaultYear, mMinimalValidYear);
+Time.Year   = MIN (Time.Year, mMaximalValidYear);
 Time.Nanosecond = 0;
 Time.TimeZone   = EFI_UNSPECIFIED_TIMEZONE;
 Time.Daylight   = 0;
@@ -358,8 +362,8 @@ PcRtcInit (
   Time.Hour   = RTC_INIT_HOUR;
   Time.Day= RTC_INIT_DAY;
   Time.Month  = RTC_INIT_MONTH;
-  Time.Year   = MAX (PcdGet16 (PcdRtcDefaultYear), PcdGet16 
(PcdMinimalValidYear));
-  Time.Year   = MIN (Time.Year, PcdGet16 (PcdMaximalValidYear));
+  Time.Year   = MAX (mRtcDefaultYear, mMinimalValidYear);
+  Time.Year   = MIN (Time.Year, mMaximalValidYear);
   Time.Nanosecond = 0;
   Time.TimeZone   = Global->SavedTimeZone;
   Time.Daylight   = Global->Daylight;
@@ -1031,8 +1035,8 @@ ConvertRtcTimeToEfiTime (
   //   Century is 19 if RTC year >= 70,
   //   Century is 20 otherwise.
   //
-  Century = (UINT8)(PcdGet16 (PcdMinimalValidYear) / 100);
-  if (Time->Year < PcdGet16 (PcdMinimalValidYear) % 100) {
+  Century = (UINT8)(mMinimalValidYear / 100);
+  if (Time->Year < mMinimalValidYear % 100) {
 Century++;
   }
 
@@ -1114,8 +1118,8 @@ RtcTimeFieldsValid (
   IN EFI_TIME  *Time
   )
 {
-  if ((Time->Year < PcdGet16 (PcdMinimalValidYear)) ||
-  (Time->Year > PcdGet16 (PcdMaximalValidYear)) ||
+  if ((Time->Year < mMinimalValidYear) ||
+  (Time->Year > mMaximalValidYear) ||
   (Time->Month < 1) ||
   (Time->Month > 12) ||
   (!DayValid (Time)) ||
diff --git a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c 
b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
index e6e9458d75..ba7e85cdfb 100644
--- a/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
+++ b/PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtcEntry.c
@@ -16,8 +16,13 @@ EFI_HANDLE  mHandle = NULL;
 
 STATIC EFI_EVENT  mVirtualAddrChangeEvent;
 
-UINTN  mRtcIndexRegister;
-UINTN  mRtcTargetRegister;
+UINTN   mRtcIndexRegister;
+UINTN   mRtcTargetRegister;
+UINTN   mRtcIndexRegisterIo;
+UINTN   mRtcTargetRegisterIo;
+UINT16  mRtcDefaultYear;
+UINT16  mMinimalValidYear;
+UINT16  mMaximalValidYear;
 
 /**
   Returns the current time and date information, and the time-keeping 
capabilities
@@ -164,8 +169,15 @@ InitializePcRtc (
   if (FeaturePcdGet (PcdRtcUseMmio)) {
 mRtcIndexRegister  = (UINTN)PcdGet64 (PcdRtcIndexRegister64);
 mRtcTargetRegister = (UINTN)PcdGet64 (PcdRtcTargetRegister64);
+  } else {
+mRtcIndexRegisterIo  = (UINTN)PcdGet8 (PcdRtcIndexRegister);
+mRtcTargetRegisterIo = (UINTN)PcdGet8 (PcdRtcTargetRegister);
   }
 
+  mRtcDefaultYear   = PcdGet16 (PcdRtcDefaultYear);
+  mMinimalValidYear = PcdGet16 (PcdMinimalValidYear);
+  mMaximalValidYear = PcdGet16 (PcdMaximalValidYear);
+
   Status = PcRtcInit (&mModuleGlobal);
   ASSERT_EFI_ERROR (Status);
 

Re: [edk2-devel] managing memory attributes in PEI

[Gerd Hoffmann]

> So my questions are:
> - do we need to retain mixed IA32 / X64 support, and if so, why? (I
> think it is related to SMM emulation but I need someone to confirm
> this)

Yes, it's SMM related.  S3 suspend in SMM-enabled builds requires
32bit PEI.

Intel seems to be working on removing the IA32 dependency, by adding
full X64 support to various places in the code base.  There have been
numerous patch sets on the list over the last months, some of them
are merged meanwhile.  As far I know the patch series addressing the
suspend problem is not yet merged (Ray, Jiewen, please correct me if
I'm wrong).

So, right now we still need that, but I expect that to change in near
future.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105118): https://edk2.groups.io/g/devel/message/105118
Mute This Topic: https://groups.io/mt/99062463/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 1/3] MdePkg/IndustryStandard: add definitions for MPAM ACPI specification

[Sami Mujawar]

Hi Rohit,

Please find my response inline marked [SAMI].

Regards,

Sami Mujawar

On 18/05/2023 04:06 pm, Rohit Mathew wrote:

From: Rohit Mathew

add definitions, macros and types for elements associated with MPAM
ACPI 2.0 specification.

Signed-off-by: Rohit Mathew
---
  MdePkg/Include/IndustryStandard/Acpi65.h |   7 +-
  MdePkg/Include/IndustryStandard/Mpam.h   | 258 
  2 files changed, 264 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi65.h 
b/MdePkg/Include/IndustryStandard/Acpi65.h
index 1e41ae9a27..8a1d3d125a 100644
--- a/MdePkg/Include/IndustryStandard/Acpi65.h
+++ b/MdePkg/Include/IndustryStandard/Acpi65.h
@@ -2,7 +2,7 @@
ACPI 6.5 definitions from the ACPI Specification Revision 6.5 Aug, 2022.
  
Copyright (c) 2017 - 2022, Intel Corporation. All rights reserved.

-  Copyright (c) 2019 - 2021, ARM Ltd. All rights reserved.
+  Copyright (c) 2019 - 2023, ARM Ltd. All rights reserved.
Copyright (c) 2023, Loongson Technology Corporation Limited. All rights 
reserved.
  
SPDX-License-Identifier: BSD-2-Clause-Patent

@@ -3251,6 +3251,11 @@ typedef struct {
  ///
  #define EFI_ACPI_6_5_XEN_PROJECT_TABLE_SIGNATURE  SIGNATURE_32('X', 'E', 'N', 
'V')
  
+///

+/// "MPAM" Memory System Resource Partitioning and Monitoring Table
+///
+#define 
EFI_ACPI_MEMORY_SYSTEM_RESOURCE_PARTITIONING_AND_MONITORING_TABLE_SIGNATURE  
SIGNATURE_32('M', 'P', 'A', 'M')
+
  #pragma pack()
  
  #endif

diff --git a/MdePkg/Include/IndustryStandard/Mpam.h 
b/MdePkg/Include/IndustryStandard/Mpam.h
new file mode 100644
index 00..5d4c466abb
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/Mpam.h
@@ -0,0 +1,258 @@
+/** @file
+  ACPI for Memory System Resource Partitioning and Monitoring 2.0 (MPAM) as
+  specified in ARM spec DEN0065
+
+  Copyright (c) 2023, Arm Limited. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Specification Reference:
+   - [1] ACPI for Memory System Resource Partitioning and Monitoring 2.0
+ (https://developer.arm.com/documentation/den0065/latest)
+
+  @par Glossary:
+- MPAM - Memory System Resource Partitioning And Monitoring
+- MSC  - Memory System Component
+- PCC  - Platform Communication Channel
+- RIS  - Resource Instance Selection
+- SMMU - Arm System Memory Management Unit
+ **/
+
+#ifndef MPAM_H_
+#define MPAM_H_
+
+#include 
+
+///
+/// MPAM Revision
+///
+#define 
EFI_ACPI_MEMORY_SYSTEM_RESOURCE_PARTITIONING_AND_MONITORING_TABLE_REVISION  
(0x01)
+
+///
+/// MPAM Interrupt mode
+///
+#define EFI_ACPI_MPAM_INTERRUPT_LEVEL_TRIGGERED  (0x0)
+#define EFI_ACPI_MPAM_INTERRUPT_EDGE_TRIGGERED   (0x1)
+
+///
+/// MPAM Interrupt type
+///
+#define EFI_ACPI_MPAM_INTERRUPT_WIRED  (0x0)
+
+///
+/// MPAM Interrupt affinity type
+///
+#define EFI_ACPI_MPAM_INTERRUPT_PROCESSOR_AFFINITY(0x0)
+#define EFI_ACPI_MPAM_INTERRUPT_PROCESSOR_CONTAINER_AFFINITY  (0x1)
+
+///
+/// MPAM MSC affinity valid
+///
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_NOT_VALID  (0x0)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID  (0x1)
+
+///
+/// MPAM Interrupt flag - bit positions
+///
+#define EFI_ACPI_MPAM_INTERRUPT_MODE_SHIFT(0)
+#define EFI_ACPI_MPAM_INTERRUPT_TYPE_SHIFT(1)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_TYPE_SHIFT   (3)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID_SHIFT  (4)
+#define EFI_ACPI_MPAM_INTERRUPT_RESERVED_SHIFT(5)
+
+///
+/// MPAM Interrupt flag - bit masks
+///
+#define EFI_ACPI_MPAM_INTERRUPT_MODE_MASK(0x1)
+#define EFI_ACPI_MPAM_INTERRUPT_TYPE_MASK(0x3)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_TYPE_MASK   (0x8)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID_MASK  (0x10)
+#define EFI_ACPI_MPAM_INTERRUPT_RESERVED_MASK(0xFFE0)
+
+///
+/// MPAM_MEMORY_LOCATOR_RESERVED_MASK should be used along with an 8 byte 
object
+/// starting at the base of the locator field.
+///
+#define EFI_ACPI_MPAM_MEM_LOCATOR_RESERVED_FIELD_MASK   (0x00FFULL)
+#define EFI_ACPI_MPAM_MEM_LOCATOR_RESERVED_FIELD_SHIFT  (0)
+
+///
+/// MPAM_MEMORY_LOCATOR_LEVEL_MASK should be used along with an 8 byte object
+///  starting at the base of the locator field.
+///
+#define EFI_ACPI_MPAM_MEM_LOCATOR_LEVEL_FIELD_MASK   (0xFF00ULL)
+#define EFI_ACPI_MPAM_MEM_LOCATOR_LEVEL_FIELD_SHIFT  (56)
+
[SAMI] Can you point me to the section in the spec where I can find this 
information, please? Are these definitions for Memory-side cache locator 
descriptor by any chance?

+///
+/// MPAM Location types
+/// as described in document [1], table 11
+///
+#define EFI_ACPI_MPAM_LOCATION_PROCESSOR_CACHE  (0x0)
+#define EFI_ACPI_MPAM_LOCATION_MEMORY   (0x1)
+#define EFI_ACPI_MPAM_LOCATION_SMMU (0x2)
+#define EFI_ACPI_MPAM_LOCATION_MEMORY_CACHE (0x3)
+#define EFI_ACPI_MPAM_LOCATION_ACPI_DEVICE  (0x4)
+#define EFI_ACPI_MPAM_LOCATION_INTERCONNECT (0x5)
+#define EFI_ACPI_MPAM_LOCATION_UNKNOW

Re: [edk2-devel] [PATCH V2 1/3] MdePkg/IndustryStandard: add definitions for MPAM ACPI specification

[Sami Mujawar]

Hi Rohit,

Just to be clear, I am looking at the following spec 
https://documentation-service.arm.com/static/638757e5e1ed1c2162fc75b2?token=


Regards,

Sami Mujawar

On 22/05/2023 01:16 pm, Sami Mujawar wrote:


Hi Rohit,

Please find my response inline marked [SAMI].

Regards,

Sami Mujawar

On 18/05/2023 04:06 pm, Rohit Mathew wrote:

From: Rohit Mathew

add definitions, macros and types for elements associated with MPAM
ACPI 2.0 specification.

Signed-off-by: Rohit Mathew
---
  MdePkg/Include/IndustryStandard/Acpi65.h |   7 +-
  MdePkg/Include/IndustryStandard/Mpam.h   | 258 
  2 files changed, 264 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi65.h 
b/MdePkg/Include/IndustryStandard/Acpi65.h
index 1e41ae9a27..8a1d3d125a 100644
--- a/MdePkg/Include/IndustryStandard/Acpi65.h
+++ b/MdePkg/Include/IndustryStandard/Acpi65.h
@@ -2,7 +2,7 @@
ACPI 6.5 definitions from the ACPI Specification Revision 6.5 Aug, 2022.
  
Copyright (c) 2017 - 2022, Intel Corporation. All rights reserved.

-  Copyright (c) 2019 - 2021, ARM Ltd. All rights reserved.
+  Copyright (c) 2019 - 2023, ARM Ltd. All rights reserved.
Copyright (c) 2023, Loongson Technology Corporation Limited. All rights 
reserved.
  
SPDX-License-Identifier: BSD-2-Clause-Patent

@@ -3251,6 +3251,11 @@ typedef struct {
  ///
  #define EFI_ACPI_6_5_XEN_PROJECT_TABLE_SIGNATURE  SIGNATURE_32('X', 'E', 'N', 
'V')
  
+///

+/// "MPAM" Memory System Resource Partitioning and Monitoring Table
+///
+#define 
EFI_ACPI_MEMORY_SYSTEM_RESOURCE_PARTITIONING_AND_MONITORING_TABLE_SIGNATURE  
SIGNATURE_32('M', 'P', 'A', 'M')
+
  #pragma pack()
  
  #endif

diff --git a/MdePkg/Include/IndustryStandard/Mpam.h 
b/MdePkg/Include/IndustryStandard/Mpam.h
new file mode 100644
index 00..5d4c466abb
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/Mpam.h
@@ -0,0 +1,258 @@
+/** @file
+  ACPI for Memory System Resource Partitioning and Monitoring 2.0 (MPAM) as
+  specified in ARM spec DEN0065
+
+  Copyright (c) 2023, Arm Limited. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Specification Reference:
+   - [1] ACPI for Memory System Resource Partitioning and Monitoring 2.0
+ (https://developer.arm.com/documentation/den0065/latest)
+
+  @par Glossary:
+- MPAM - Memory System Resource Partitioning And Monitoring
+- MSC  - Memory System Component
+- PCC  - Platform Communication Channel
+- RIS  - Resource Instance Selection
+- SMMU - Arm System Memory Management Unit
+ **/
+
+#ifndef MPAM_H_
+#define MPAM_H_
+
+#include 
+
+///
+/// MPAM Revision
+///
+#define 
EFI_ACPI_MEMORY_SYSTEM_RESOURCE_PARTITIONING_AND_MONITORING_TABLE_REVISION  
(0x01)
+
+///
+/// MPAM Interrupt mode
+///
+#define EFI_ACPI_MPAM_INTERRUPT_LEVEL_TRIGGERED  (0x0)
+#define EFI_ACPI_MPAM_INTERRUPT_EDGE_TRIGGERED   (0x1)
+
+///
+/// MPAM Interrupt type
+///
+#define EFI_ACPI_MPAM_INTERRUPT_WIRED  (0x0)
+
+///
+/// MPAM Interrupt affinity type
+///
+#define EFI_ACPI_MPAM_INTERRUPT_PROCESSOR_AFFINITY(0x0)
+#define EFI_ACPI_MPAM_INTERRUPT_PROCESSOR_CONTAINER_AFFINITY  (0x1)
+
+///
+/// MPAM MSC affinity valid
+///
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_NOT_VALID  (0x0)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID  (0x1)
+
+///
+/// MPAM Interrupt flag - bit positions
+///
+#define EFI_ACPI_MPAM_INTERRUPT_MODE_SHIFT(0)
+#define EFI_ACPI_MPAM_INTERRUPT_TYPE_SHIFT(1)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_TYPE_SHIFT   (3)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID_SHIFT  (4)
+#define EFI_ACPI_MPAM_INTERRUPT_RESERVED_SHIFT(5)
+
+///
+/// MPAM Interrupt flag - bit masks
+///
+#define EFI_ACPI_MPAM_INTERRUPT_MODE_MASK(0x1)
+#define EFI_ACPI_MPAM_INTERRUPT_TYPE_MASK(0x3)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_TYPE_MASK   (0x8)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID_MASK  (0x10)
+#define EFI_ACPI_MPAM_INTERRUPT_RESERVED_MASK(0xFFE0)
+
+///
+/// MPAM_MEMORY_LOCATOR_RESERVED_MASK should be used along with an 8 byte 
object
+/// starting at the base of the locator field.
+///
+#define EFI_ACPI_MPAM_MEM_LOCATOR_RESERVED_FIELD_MASK   (0x00FFULL)
+#define EFI_ACPI_MPAM_MEM_LOCATOR_RESERVED_FIELD_SHIFT  (0)
+
+///
+/// MPAM_MEMORY_LOCATOR_LEVEL_MASK should be used along with an 8 byte object
+///  starting at the base of the locator field.
+///
+#define EFI_ACPI_MPAM_MEM_LOCATOR_LEVEL_FIELD_MASK   (0xFF00ULL)
+#define EFI_ACPI_MPAM_MEM_LOCATOR_LEVEL_FIELD_SHIFT  (56)
+
[SAMI] Can you point me to the section in the spec where I can find 
this information, please? Are these definitions for Memory-side cache 
locator descriptor by any chance?

+///
+/// MPAM Location types
+/// as described in document [1], table 11
+///
+#define EFI_ACPI_MPAM_LOCATION_PROCESSOR_CACHE  (0x0)
+#define EFI_ACPI_MPAM_LOCATION_MEMORY   (0x1)
+#define EFI_ACPI_MPAM_LOCATION_SMMU

Re: [edk2-devel] [PATCH v4 01/10] BaseTools: add BASETOOLS define

[Gerd Hoffmann]

  Hi,

So, after a way to long time gap, I finally found the time to look at
this again.  This time tried both gcc and clang.

Just dropping the visibility hidden #pragma works fine for gcc.  It also
works with clang for DEBUG and RELEASE builds, but not for NOOPT builds.

> > Automatically detecting freestanding vs. hosted would be even better,
> > anyone knows whenever there is a define which can be used for this?  At
> > least the gcc man page doesn't mention any ...
> >
> 
> ard@gambale:~/linux-build-x86$ gcc -dM -E -o - -xc - <<< ""|grep HOSTED
> #define __STDC_HOSTED__ 1
> ard@gambale:~/linux-build-x86$ gcc -ffreestanding -dM -E -o - -xc -
> <<< ""|grep HOSTED
> #define __STDC_HOSTED__ 0

Problem with this is we don't build with -ffreestanding.

Simply adding it breaks (not surprisingly) the hosted builds,
specifically various test cases such as MdePkg/Test/MdePkgHostTest.dsc.

Looking through BaseTools/Conf/tools_def.template I can't see some
way to apply options only to hosted or freestanding builds.  Apparently
that information is not anywhere in the *.inf files, or did I miss
something?

So back to the approach of adding a #define?

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105121): https://edk2.groups.io/g/devel/message/105121
Mute This Topic: https://groups.io/mt/98257896/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 01/10] BaseTools: add BASETOOLS define

[Ard Biesheuvel]

On Mon, 22 May 2023 at 14:28, Gerd Hoffmann  wrote:
>
>   Hi,
>
> So, after a way to long time gap, I finally found the time to look at
> this again.  This time tried both gcc and clang.
>
> Just dropping the visibility hidden #pragma works fine for gcc.  It also
> works with clang for DEBUG and RELEASE builds, but not for NOOPT builds.
>

So what failures are you seeing in this case? I assume this is using LLD.

So the problem with LLD is that it does not update the static
relocations it emits into the executables, so even if the linker
relaxes any GOT based references, the relocation entry still claims
that a GOT based reference exists.

It should be possible in principle to detect this casein GenFw, but
this would involve decoding the instruction to decide whether it uses
a memory operand or not, and this doesn't seem worth the effort to me.

Recent clang does have a '-fdirect-access-external-data' switch which
should suppress these references, maybe in combination with
-fvisibility=hidden?
(The latter is usually insufficient by itself)


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105122): https://edk2.groups.io/g/devel/message/105122
Mute This Topic: https://groups.io/mt/98257896/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V2 1/3] MdePkg/IndustryStandard: add definitions for MPAM ACPI specification

[Rohit Mathew]

Hi Sami,

Thank you for the review. Please find my comments inline.

Regards,
Rohit
From: Sami Mujawar 
Sent: Monday, May 22, 2023 1:17 PM
To: Rohit Mathew ; devel@edk2.groups.io
Cc: Michael D Kinney ; Liming Gao 
; Thomas Abraham ; James 
Morse ; nd 
Subject: Re: [PATCH V2 1/3] MdePkg/IndustryStandard: add definitions for MPAM 
ACPI specification


Hi Rohit,

Please find my response inline marked [SAMI].

Regards,

Sami Mujawar
On 18/05/2023 04:06 pm, Rohit Mathew wrote:

From: Rohit Mathew 



add definitions, macros and types for elements associated with MPAM

ACPI 2.0 specification.



Signed-off-by: Rohit Mathew 

---

 MdePkg/Include/IndustryStandard/Acpi65.h |   7 +-

 MdePkg/Include/IndustryStandard/Mpam.h   | 258 

 2 files changed, 264 insertions(+), 1 deletion(-)



diff --git a/MdePkg/Include/IndustryStandard/Acpi65.h 
b/MdePkg/Include/IndustryStandard/Acpi65.h

index 1e41ae9a27..8a1d3d125a 100644

--- a/MdePkg/Include/IndustryStandard/Acpi65.h

+++ b/MdePkg/Include/IndustryStandard/Acpi65.h

@@ -2,7 +2,7 @@

   ACPI 6.5 definitions from the ACPI Specification Revision 6.5 Aug, 2022.



   Copyright (c) 2017 - 2022, Intel Corporation. All rights reserved.

-  Copyright (c) 2019 - 2021, ARM Ltd. All rights reserved.

+  Copyright (c) 2019 - 2023, ARM Ltd. All rights reserved.

   Copyright (c) 2023, Loongson Technology Corporation Limited. All rights 
reserved.



   SPDX-License-Identifier: BSD-2-Clause-Patent

@@ -3251,6 +3251,11 @@ typedef struct {

 ///

 #define EFI_ACPI_6_5_XEN_PROJECT_TABLE_SIGNATURE  SIGNATURE_32('X', 'E', 'N', 
'V')



+///

+/// "MPAM" Memory System Resource Partitioning and Monitoring Table

+///

+#define 
EFI_ACPI_MEMORY_SYSTEM_RESOURCE_PARTITIONING_AND_MONITORING_TABLE_SIGNATURE  
SIGNATURE_32('M', 'P', 'A', 'M')

+

 #pragma pack()



 #endif

diff --git a/MdePkg/Include/IndustryStandard/Mpam.h 
b/MdePkg/Include/IndustryStandard/Mpam.h

new file mode 100644

index 00..5d4c466abb

--- /dev/null

+++ b/MdePkg/Include/IndustryStandard/Mpam.h

@@ -0,0 +1,258 @@

+/** @file

+  ACPI for Memory System Resource Partitioning and Monitoring 2.0 (MPAM) as

+  specified in ARM spec DEN0065

+

+  Copyright (c) 2023, Arm Limited. All rights reserved.

+

+  SPDX-License-Identifier: BSD-2-Clause-Patent

+

+  @par Specification Reference:

+   - [1] ACPI for Memory System Resource Partitioning and Monitoring 2.0

+ (https://developer.arm.com/documentation/den0065/latest)

+

+  @par Glossary:

+- MPAM - Memory System Resource Partitioning And Monitoring

+- MSC  - Memory System Component

+- PCC  - Platform Communication Channel

+- RIS  - Resource Instance Selection

+- SMMU - Arm System Memory Management Unit

+ **/

+

+#ifndef MPAM_H_

+#define MPAM_H_

+

+#include 

+

+///

+/// MPAM Revision

+///

+#define 
EFI_ACPI_MEMORY_SYSTEM_RESOURCE_PARTITIONING_AND_MONITORING_TABLE_REVISION  
(0x01)

+

+///

+/// MPAM Interrupt mode

+///

+#define EFI_ACPI_MPAM_INTERRUPT_LEVEL_TRIGGERED  (0x0)

+#define EFI_ACPI_MPAM_INTERRUPT_EDGE_TRIGGERED   (0x1)

+

+///

+/// MPAM Interrupt type

+///

+#define EFI_ACPI_MPAM_INTERRUPT_WIRED  (0x0)

+

+///

+/// MPAM Interrupt affinity type

+///

+#define EFI_ACPI_MPAM_INTERRUPT_PROCESSOR_AFFINITY(0x0)

+#define EFI_ACPI_MPAM_INTERRUPT_PROCESSOR_CONTAINER_AFFINITY  (0x1)

+

+///

+/// MPAM MSC affinity valid

+///

+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_NOT_VALID  (0x0)

+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID  (0x1)

+

+///

+/// MPAM Interrupt flag - bit positions

+///

+#define EFI_ACPI_MPAM_INTERRUPT_MODE_SHIFT(0)

+#define EFI_ACPI_MPAM_INTERRUPT_TYPE_SHIFT(1)

+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_TYPE_SHIFT   (3)

+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID_SHIFT  (4)

+#define EFI_ACPI_MPAM_INTERRUPT_RESERVED_SHIFT(5)

+

+///

+/// MPAM Interrupt flag - bit masks

+///

+#define EFI_ACPI_MPAM_INTERRUPT_MODE_MASK(0x1)

+#define EFI_ACPI_MPAM_INTERRUPT_TYPE_MASK(0x3)

+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_TYPE_MASK   (0x8)

+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID_MASK  (0x10)

+#define EFI_ACPI_MPAM_INTERRUPT_RESERVED_MASK(0xFFE0)

+

+///

+/// MPAM_MEMORY_LOCATOR_RESERVED_MASK should be used along with an 8 byte 
object

+/// starting at the base of the locator field.

+///

+#define EFI_ACPI_MPAM_MEM_LOCATOR_RESERVED_FIELD_MASK   (0x00FFULL)

+#define EFI_ACPI_MPAM_MEM_LOCATOR_RESERVED_FIELD_SHIFT  (0)

+

+///

+/// MPAM_MEMORY_LOCATOR_LEVEL_MASK should be used along with an 8 byte object

+///  starting at the base of the locator field.

+///

+#define EFI_ACPI_MPAM_MEM_LOCATOR_LEVEL_FIELD_MASK   (0xFF00ULL)

+#define EFI_ACPI_MPAM_MEM_LOCATOR_LEVEL_FIELD_SHIFT  (56)

+
[SAMI] Can you point me to the section in the spec where I can find this 
information, please? Are these defi

Re: [edk2-devel] [PATCH V2 1/3] MdePkg/IndustryStandard: add definitions for MPAM ACPI specification

[Sami Mujawar]

Hi Rohit,

Please send an updated series with the issues fixed.

Regards,

Sami Mujawar

From: Rohit Mathew 
Date: Monday, 22 May 2023 at 14:08
To: Sami Mujawar , "devel@edk2.groups.io" 

Cc: Michael D Kinney , Liming Gao 
, Thomas Abraham , James 
Morse , nd 
Subject: RE: [PATCH V2 1/3] MdePkg/IndustryStandard: add definitions for MPAM 
ACPI specification

Hi Sami,

Thank you for the review. Please find my comments inline.

Regards,
Rohit
From: Sami Mujawar 
Sent: Monday, May 22, 2023 1:17 PM
To: Rohit Mathew ; devel@edk2.groups.io
Cc: Michael D Kinney ; Liming Gao 
; Thomas Abraham ; James 
Morse ; nd 
Subject: Re: [PATCH V2 1/3] MdePkg/IndustryStandard: add definitions for MPAM 
ACPI specification


Hi Rohit,

Please find my response inline marked [SAMI].

Regards,

Sami Mujawar
On 18/05/2023 04:06 pm, Rohit Mathew wrote:

From: Rohit Mathew 



add definitions, macros and types for elements associated with MPAM

ACPI 2.0 specification.



Signed-off-by: Rohit Mathew 

---

 MdePkg/Include/IndustryStandard/Acpi65.h |   7 +-

 MdePkg/Include/IndustryStandard/Mpam.h   | 258 

 2 files changed, 264 insertions(+), 1 deletion(-)



diff --git a/MdePkg/Include/IndustryStandard/Acpi65.h 
b/MdePkg/Include/IndustryStandard/Acpi65.h

index 1e41ae9a27..8a1d3d125a 100644

--- a/MdePkg/Include/IndustryStandard/Acpi65.h

+++ b/MdePkg/Include/IndustryStandard/Acpi65.h

@@ -2,7 +2,7 @@

   ACPI 6.5 definitions from the ACPI Specification Revision 6.5 Aug, 2022.



   Copyright (c) 2017 - 2022, Intel Corporation. All rights reserved.

-  Copyright (c) 2019 - 2021, ARM Ltd. All rights reserved.

+  Copyright (c) 2019 - 2023, ARM Ltd. All rights reserved.

   Copyright (c) 2023, Loongson Technology Corporation Limited. All rights 
reserved.



   SPDX-License-Identifier: BSD-2-Clause-Patent

@@ -3251,6 +3251,11 @@ typedef struct {

 ///

 #define EFI_ACPI_6_5_XEN_PROJECT_TABLE_SIGNATURE  SIGNATURE_32('X', 'E', 'N', 
'V')



+///

+/// "MPAM" Memory System Resource Partitioning and Monitoring Table

+///

+#define 
EFI_ACPI_MEMORY_SYSTEM_RESOURCE_PARTITIONING_AND_MONITORING_TABLE_SIGNATURE  
SIGNATURE_32('M', 'P', 'A', 'M')

+

 #pragma pack()



 #endif

diff --git a/MdePkg/Include/IndustryStandard/Mpam.h 
b/MdePkg/Include/IndustryStandard/Mpam.h

new file mode 100644

index 00..5d4c466abb

--- /dev/null

+++ b/MdePkg/Include/IndustryStandard/Mpam.h

@@ -0,0 +1,258 @@

+/** @file

+  ACPI for Memory System Resource Partitioning and Monitoring 2.0 (MPAM) as

+  specified in ARM spec DEN0065

+

+  Copyright (c) 2023, Arm Limited. All rights reserved.

+

+  SPDX-License-Identifier: BSD-2-Clause-Patent

+

+  @par Specification Reference:

+   - [1] ACPI for Memory System Resource Partitioning and Monitoring 2.0

+ (https://developer.arm.com/documentation/den0065/latest)

+

+  @par Glossary:

+- MPAM - Memory System Resource Partitioning And Monitoring

+- MSC  - Memory System Component

+- PCC  - Platform Communication Channel

+- RIS  - Resource Instance Selection

+- SMMU - Arm System Memory Management Unit

+ **/

+

+#ifndef MPAM_H_

+#define MPAM_H_

+

+#include 

+

+///

+/// MPAM Revision

+///

+#define 
EFI_ACPI_MEMORY_SYSTEM_RESOURCE_PARTITIONING_AND_MONITORING_TABLE_REVISION  
(0x01)

+

+///

+/// MPAM Interrupt mode

+///

+#define EFI_ACPI_MPAM_INTERRUPT_LEVEL_TRIGGERED  (0x0)

+#define EFI_ACPI_MPAM_INTERRUPT_EDGE_TRIGGERED   (0x1)

+

+///

+/// MPAM Interrupt type

+///

+#define EFI_ACPI_MPAM_INTERRUPT_WIRED  (0x0)

+

+///

+/// MPAM Interrupt affinity type

+///

+#define EFI_ACPI_MPAM_INTERRUPT_PROCESSOR_AFFINITY(0x0)

+#define EFI_ACPI_MPAM_INTERRUPT_PROCESSOR_CONTAINER_AFFINITY  (0x1)

+

+///

+/// MPAM MSC affinity valid

+///

+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_NOT_VALID  (0x0)

+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID  (0x1)

+

+///

+/// MPAM Interrupt flag - bit positions

+///

+#define EFI_ACPI_MPAM_INTERRUPT_MODE_SHIFT(0)

+#define EFI_ACPI_MPAM_INTERRUPT_TYPE_SHIFT(1)

+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_TYPE_SHIFT   (3)

+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID_SHIFT  (4)

+#define EFI_ACPI_MPAM_INTERRUPT_RESERVED_SHIFT(5)

+

+///

+/// MPAM Interrupt flag - bit masks

+///

+#define EFI_ACPI_MPAM_INTERRUPT_MODE_MASK(0x1)

+#define EFI_ACPI_MPAM_INTERRUPT_TYPE_MASK(0x3)

+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_TYPE_MASK   (0x8)

+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID_MASK  (0x10)

+#define EFI_ACPI_MPAM_INTERRUPT_RESERVED_MASK(0xFFE0)

+

+///

+/// MPAM_MEMORY_LOCATOR_RESERVED_MASK should be used along with an 8 byte 
object

+/// starting at the base of the locator field.

+///

+#define EFI_ACPI_MPAM_MEM_LOCATOR_RESERVED_FIELD_MASK   (0x00FFULL)

+#define EFI_ACPI_MPAM_MEM_LOCATOR_RESERVED_FIELD_SHIFT  (0)

+

+///

+/// MPAM_MEMORY_LOCATOR_L

Re: [edk2-devel] [PATCH v2 3/4] OvmfPkg/PlatformInitLib: dynamic mmio window size

[Fiona Ebner]

Am 22.05.23 um 13:12 schrieb Gerd Hoffmann:> The patch below fixes it
for me.  Can you confirm this?

Yes, it fixes the issue for me too :)

Best Regards,
Fiona



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105125): https://edk2.groups.io/g/devel/message/105125
Mute This Topic: https://groups.io/mt/94113626/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 01/10] BaseTools: add BASETOOLS define

[Gerd Hoffmann]

On Mon, May 22, 2023 at 02:55:43PM +0200, Ard Biesheuvel wrote:
> On Mon, 22 May 2023 at 14:28, Gerd Hoffmann  wrote:
> >
> >   Hi,
> >
> > So, after a way to long time gap, I finally found the time to look at
> > this again.  This time tried both gcc and clang.
> >
> > Just dropping the visibility hidden #pragma works fine for gcc.  It also
> > works with clang for DEBUG and RELEASE builds, but not for NOOPT builds.
> 
> So what failures are you seeing in this case?

"GenFw" -e UEFI_DRIVER -o 
/home/kraxel/projects/edk2/Build/OvmfX64/NOOPT_CLANGDWARF/X64/FatPkg/EnhancedFatDxe/Fat/OUTPUT/Fat.efi
 
/home/kraxel/projects/edk2/Build/OvmfX64/NOOPT_CLANGDWARF/X64/FatPkg/EnhancedFatDxe/Fat/DEBUG/Fat.dll
GenFw: ERROR 3000: Unsupported
  FindElfGOTSectionFromGOTEntryElfRva: GOT entries found in multiple sections.
make: *** [GNUmakefile:450: 
/home/kraxel/projects/edk2/Build/OvmfX64/NOOPT_CLANGDWARF/X64/FatPkg/EnhancedFatDxe/Fat/OUTPUT/Fat.efi]
 Error 1

> I assume this is using LLD.

Yes, there is '-fuse-ld=lld' on the clang command line.

> So the problem with LLD is that it does not update the static
> relocations it emits into the executables, so even if the linker
> relaxes any GOT based references, the relocation entry still claims
> that a GOT based reference exists.

# objdump -x 
/home/kraxel/projects/edk2/Build/OvmfX64/NOOPT_CLANGDWARF/X64/FatPkg/EnhancedFatDxe/Fat/DEBUG/Fat.dll
 | grep -i got | head
134e R_X86_64_REX_GOTPCRELX  gBS-0x0004
1ab9 R_X86_64_REX_GOTPCRELX  gBS-0x0004
1bbf R_X86_64_REX_GOTPCRELX  gBS-0x0004
21c7 R_X86_64_REX_GOTPCRELX  FatFsLock-0x0004
3eb1 R_X86_64_REX_GOTPCRELX  gFatDriverBinding-0x0004
3ebc R_X86_64_REX_GOTPCRELX  
gEfiDiskIoProtocolGuid-0x0004
4695 R_X86_64_REX_GOTPCRELX  FatFsLock-0x0004
4bfc R_X86_64_REX_GOTPCRELX  FatFsLock-0x0004
4c6e R_X86_64_REX_GOTPCRELX  FatFileInterface-0x0004
4d74 R_X86_64_REX_GOTPCRELX  FatFsLock-0x0004

> Recent clang does have a '-fdirect-access-external-data' switch which
> should suppress these references, maybe in combination with
> -fvisibility=hidden?

I'll try that.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105126): https://edk2.groups.io/g/devel/message/105126
Mute This Topic: https://groups.io/mt/98257896/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-stable202305] ArmPkg/ArmMmuLib: Add missing ISB after page table update

[Michael D Kinney]

Acked-by: Michael D Kinney 

No objection to merging for the stable tag.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Leif
> Lindholm
> Sent: Monday, May 22, 2023 3:56 AM
> To: Ard Biesheuvel 
> Cc: devel@edk2.groups.io; Gao, Liming ;
> Kinney, Michael D ; Oliver Steffen
> 
> Subject: Re: [edk2-devel] [PATCH edk2-stable202305] ArmPkg/ArmMmuLib:
> Add missing ISB after page table update
> 
> On Sat, May 20, 2023 at 11:19:58 +0200, Ard Biesheuvel wrote:
> > The helper that updates live page table entries writes a zero entry,
> > invalidates the covered address range from the TLBs, and finally writes
> > the actual entry. This ensures that no TLB conflicts can occur.
> >
> > Writing the final entry needs to complete before any translations can be
> > performed, as otherwise, the zero entry, which describes an invalid
> > translation, may be observed by the page table walker, resulting in a
> > translation fault. For this reason, the final write is followed by a DSB
> > barrier instruction.
> >
> > However, this barrier will not stall the pipeline, and instruction
> > fetches may still hit this invalid translation, as has been observed and
> > reported by Oliver. To ensure that the new translation is fully active
> > before returning from this helper, we have to insert an ISB barrier as
> > well.
> >
> > Cc: Liming Gao 
> > Cc: Leif Lindholm 
> > Cc: Michael D Kinney 
> > Reported-by: Oliver Steffen 
> > Tested-by: Oliver Steffen 
> > Signed-off-by: Ard Biesheuvel 
> 
> Reviewed-by: Leif Lindholm 
> 
> We need this in the stable tag.
> 
> Note: the isb instruction forces the synchronization of certain
> architectural events. It has no other effects. I.e., any issues
> exposed by this addition would already have been present before it.
> 
> As such, I would suggest this addition need *not* affect the stable
> tag schedule.
> 
> /
> Leif
> 
> > ---
> >  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git
> a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > index 887439bc042f0f16..1f0d8057926933d7 100644
> > --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > @@ -65,6 +65,7 @@
> >// write updated entry
> >str   x1, [x0]
> >dsb   nshst
> > +  isb
> >
> >  .L2_\@:
> >.endm
> > --
> > 2.39.2
> >
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105127): https://edk2.groups.io/g/devel/message/105127
Mute This Topic: https://groups.io/mt/99027974/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 01/10] BaseTools: add BASETOOLS define

[Gerd Hoffmann]

  Hi,

> > Recent clang does have a '-fdirect-access-external-data' switch which
> > should suppress these references, maybe in combination with
> > -fvisibility=hidden?
> 
> I'll try that.

Works (test patch below for reference).

thanks,
  Gerd

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 503a6687c1f0..f19992f68a84 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -1929,7 +1929,7 @@ RELEASE_CLANGDWARF_X64_CC_FLAGS   = 
DEF(CLANGDWARF_ALL_CC_FLAGS) -m64 "-DEFI
 RELEASE_CLANGDWARF_X64_DLINK_FLAGS= DEF(CLANGDWARF_IA32_X64_DLINK_FLAGS) 
-flto -Wl,-O3 -Wl,-melf_x86_64 -Wl,--oformat,elf64-x86-64 -Wl,-pie 
-mcmodel=small -Wl,--apply-dynamic-relocs
 RELEASE_CLANGDWARF_X64_DLINK2_FLAGS   = DEF(CLANGDWARF_X64_DLINK2_FLAGS) -O3 
-fuse-ld=lld
 
-NOOPT_CLANGDWARF_X64_CC_FLAGS = DEF(CLANGDWARF_ALL_CC_FLAGS) -m64 
"-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -O0 
DEF(CLANGDWARF_X64_TARGET) -g
+NOOPT_CLANGDWARF_X64_CC_FLAGS = DEF(CLANGDWARF_ALL_CC_FLAGS) -m64 
"-DEFIAPI=__attribute__((ms_abi))" -mno-red-zone -mcmodel=small -fpie -O0 
DEF(CLANGDWARF_X64_TARGET) -g -fdirect-access-external-data
 NOOPT_CLANGDWARF_X64_DLINK_FLAGS  = DEF(CLANGDWARF_IA32_X64_DLINK_FLAGS) 
-Wl,-O0 -Wl,-melf_x86_64 -Wl,--oformat,elf64-x86-64 -Wl,-pie -mcmodel=small 
-Wl,--apply-dynamic-relocs
 NOOPT_CLANGDWARF_X64_DLINK2_FLAGS = DEF(CLANGDWARF_X64_DLINK2_FLAGS) -O0 
-fuse-ld=lld
 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105128): https://edk2.groups.io/g/devel/message/105128
Mute This Topic: https://groups.io/mt/98257896/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V3 0/3] MPAM ACPI definitions and parser

[Rohit Mathew]

This series adds the following
 -  definitions corresponding to MPAM ACPI 2.0 specification.
 -  MPAM parser

An MPAM ACPI table formulated using the newly added MPAM ACPI definitions were
validated on the linux kernel tree at [1]. The same table was parsed via
acpiview using the newly added parser. Certain aspects of the MPAM ACPI
specification are still not implemented by the kernel tree. These aspects were
verified only using acpiview.

Changes since V1:
 -  Addressed comments on MPAM ACPI definitions from Sami.
 -  V1 did not incorporate the parser. V2 has this implemented.

Changes since V2:
 -  Addressed comments related to Interface/Link type defintions from Sami.

Changes can be found at:

https://github.com/rohit-arm/edk2/tree/mpam_acpi

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git/log/?h=mpam/snapshot/v6.2

Rohit Mathew (3):
  MdePkg/IndustryStandard: Add definitions for MPAM ACPI specification
  ShellPkg: acpiview: Add routine to print 16 chars
  ShellPkg/AcpiView: Add MPAM Parser

 MdePkg/Include/IndustryStandard/Acpi65.h | 
   7 +-
 MdePkg/Include/IndustryStandard/Mpam.h   | 
 260 
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c| 
  39 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h| 
  39 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Mpam/MpamParser.c   | 
1331 
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Mpam/MpamParser.h   | 
  25 +
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.c   | 
   3 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.inf | 
   4 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni | 
   3 +-
 9 files changed, 1705 insertions(+), 6 deletions(-)
 create mode 100644 MdePkg/Include/IndustryStandard/Mpam.h
 create mode 100644 
ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Mpam/MpamParser.c
 create mode 100644 
ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Mpam/MpamParser.h

-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105129): https://edk2.groups.io/g/devel/message/105129
Mute This Topic: https://groups.io/mt/99066152/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V3 1/3] MdePkg/IndustryStandard: Add definitions for MPAM ACPI specification

[Rohit Mathew]

From: Rohit Mathew 

Add definitions, macros and types for elements associated with MPAM
ACPI 2.0 specification.

Signed-off-by: Rohit Mathew 
---
 MdePkg/Include/IndustryStandard/Acpi65.h |   7 +-
 MdePkg/Include/IndustryStandard/Mpam.h   | 260 
 2 files changed, 266 insertions(+), 1 deletion(-)

diff --git a/MdePkg/Include/IndustryStandard/Acpi65.h 
b/MdePkg/Include/IndustryStandard/Acpi65.h
index 1e41ae9a27..8a1d3d125a 100644
--- a/MdePkg/Include/IndustryStandard/Acpi65.h
+++ b/MdePkg/Include/IndustryStandard/Acpi65.h
@@ -2,7 +2,7 @@
   ACPI 6.5 definitions from the ACPI Specification Revision 6.5 Aug, 2022.
 
   Copyright (c) 2017 - 2022, Intel Corporation. All rights reserved.
-  Copyright (c) 2019 - 2021, ARM Ltd. All rights reserved.
+  Copyright (c) 2019 - 2023, ARM Ltd. All rights reserved.
   Copyright (c) 2023, Loongson Technology Corporation Limited. All rights 
reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -3251,6 +3251,11 @@ typedef struct {
 ///
 #define EFI_ACPI_6_5_XEN_PROJECT_TABLE_SIGNATURE  SIGNATURE_32('X', 'E', 'N', 
'V')
 
+///
+/// "MPAM" Memory System Resource Partitioning and Monitoring Table
+///
+#define 
EFI_ACPI_MEMORY_SYSTEM_RESOURCE_PARTITIONING_AND_MONITORING_TABLE_SIGNATURE  
SIGNATURE_32('M', 'P', 'A', 'M')
+
 #pragma pack()
 
 #endif
diff --git a/MdePkg/Include/IndustryStandard/Mpam.h 
b/MdePkg/Include/IndustryStandard/Mpam.h
new file mode 100644
index 00..30b69c869e
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/Mpam.h
@@ -0,0 +1,260 @@
+/** @file
+  ACPI for Memory System Resource Partitioning and Monitoring 2.0 (MPAM) as
+  specified in ARM spec DEN0065
+
+  Copyright (c) 2023, Arm Limited. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Specification Reference:
+   - [1] ACPI for Memory System Resource Partitioning and Monitoring 2.0
+ (https://developer.arm.com/documentation/den0065/latest)
+
+  @par Glossary:
+- MPAM - Memory System Resource Partitioning And Monitoring
+- MSC  - Memory System Component
+- PCC  - Platform Communication Channel
+- RIS  - Resource Instance Selection
+- SMMU - Arm System Memory Management Unit
+ **/
+
+#ifndef MPAM_H_
+#define MPAM_H_
+
+#include 
+
+///
+/// MPAM Revision
+///
+#define 
EFI_ACPI_MEMORY_SYSTEM_RESOURCE_PARTITIONING_AND_MONITORING_TABLE_REVISION  
(0x01)
+
+///
+/// MPAM Interrupt mode
+///
+#define EFI_ACPI_MPAM_INTERRUPT_LEVEL_TRIGGERED  (0x0)
+#define EFI_ACPI_MPAM_INTERRUPT_EDGE_TRIGGERED   (0x1)
+
+///
+/// MPAM Interrupt type
+///
+#define EFI_ACPI_MPAM_INTERRUPT_WIRED  (0x0)
+
+///
+/// MPAM Interrupt affinity type
+///
+#define EFI_ACPI_MPAM_INTERRUPT_PROCESSOR_AFFINITY(0x0)
+#define EFI_ACPI_MPAM_INTERRUPT_PROCESSOR_CONTAINER_AFFINITY  (0x1)
+
+///
+/// MPAM MSC affinity valid
+///
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_NOT_VALID  (0x0)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID  (0x1)
+
+///
+/// MPAM Interrupt flag - bit positions
+///
+#define EFI_ACPI_MPAM_INTERRUPT_MODE_SHIFT(0)
+#define EFI_ACPI_MPAM_INTERRUPT_TYPE_SHIFT(1)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_TYPE_SHIFT   (3)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID_SHIFT  (4)
+#define EFI_ACPI_MPAM_INTERRUPT_RESERVED_SHIFT(5)
+
+///
+/// MPAM Interrupt flag - bit masks
+///
+#define EFI_ACPI_MPAM_INTERRUPT_MODE_MASK(0x1)
+#define EFI_ACPI_MPAM_INTERRUPT_TYPE_MASK(0x3)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_TYPE_MASK   (0x8)
+#define EFI_ACPI_MPAM_INTERRUPT_AFFINITY_VALID_MASK  (0x10)
+#define EFI_ACPI_MPAM_INTERRUPT_RESERVED_MASK(0xFFE0)
+
+///
+/// EFI_ACPI_MPAM_MEM_CACHE_LOCATOR_RESERVED_FIELD_MASK should be used along
+/// with an 8 byte object starting at the base of the locator field.
+///
+#define EFI_ACPI_MPAM_MEM_CACHE_LOCATOR_RESERVED_FIELD_MASK   
(0x00FFULL)
+#define EFI_ACPI_MPAM_MEM_CACHE_LOCATOR_RESERVED_FIELD_SHIFT  (0)
+
+///
+/// EFI_ACPI_MPAM_MEM_CACHE_LOCATOR_LEVEL_FIELD_MASK should be used along with
+/// an 8 byte object starting at the base of the locator field.
+///
+#define EFI_ACPI_MPAM_MEM_CACHE_LOCATOR_LEVEL_FIELD_MASK   
(0xFF00ULL)
+#define EFI_ACPI_MPAM_MEM_CACHE_LOCATOR_LEVEL_FIELD_SHIFT  (56)
+
+///
+/// MPAM Location types
+/// as described in document [1], table 11.
+///
+#define EFI_ACPI_MPAM_LOCATION_PROCESSOR_CACHE  (0x0)
+#define EFI_ACPI_MPAM_LOCATION_MEMORY   (0x1)
+#define EFI_ACPI_MPAM_LOCATION_SMMU (0x2)
+#define EFI_ACPI_MPAM_LOCATION_MEMORY_CACHE (0x3)
+#define EFI_ACPI_MPAM_LOCATION_ACPI_DEVICE  (0x4)
+#define EFI_ACPI_MPAM_LOCATION_INTERCONNECT (0x5)
+#define EFI_ACPI_MPAM_LOCATION_UNKNOWN  (0xFF)
+
+///
+/// MPAM Interface types
+/// as described in document[1], table 4.
+///
+#define EFI_ACPI_MPAM_INTERFACE_MMIO  (0x00)
+#define EFI_ACPI_MPAM_INTERFACE_PCC   (0x0A)
+
+///
+/// MPAM Link types
+/// as described in document [1], table

[edk2-devel] [PATCH V3 2/3] ShellPkg: acpiview: Add routine to print 16 chars

[Rohit Mathew]

Certain ACPI tables like MPAM has fields which are 16 bytes long.
Routines similar to Dump12Chars but for 16 characters are required to
print such fields. Add Dump16Chars routine to satisfy this requirement.

Signed-off-by: Rohit Mathew 
---
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c | 39 
+++-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h | 18 -
 2 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
index eac9286176..87f55098b8 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
@@ -1,7 +1,7 @@
 /** @file
   ACPI parser
 
-  Copyright (c) 2016 - 2021, Arm Limited. All rights reserved.
+  Copyright (c) 2016 - 2023, Arm Limited. All rights reserved.
   Copyright (c) 2022, AMD Incorporated. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
@@ -449,6 +449,43 @@ Dump12Chars (
 );
 }
 
+/**
+  This function traces 16 characters which can be optionally
+  formated using the format string if specified.
+
+  If no format string is specified the Format must be NULL.
+
+  @param [in] Format  Optional format string for tracing the data.
+  @param [in] Ptr Pointer to the start of the buffer.
+**/
+VOID
+EFIAPI
+Dump16Chars (
+  IN CONST CHAR16  *Format OPTIONAL,
+  IN UINT8 *Ptr
+  )
+{
+  Print (
+(Format != NULL) ? Format : L"%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c",
+Ptr[0],
+Ptr[1],
+Ptr[2],
+Ptr[3],
+Ptr[4],
+Ptr[5],
+Ptr[6],
+Ptr[7],
+Ptr[8],
+Ptr[9],
+Ptr[10],
+Ptr[11],
+Ptr[12],
+Ptr[13],
+Ptr[14],
+Ptr[15]
+);
+}
+
 /**
   This function indents and prints the ACPI table Field Name.
 
diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
index 4b4397961b..c9f41650d9 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
@@ -2,7 +2,7 @@
   Header file for ACPI parser
 
   Copyright (c) 2022, NVIDIA CORPORATION. All rights reserved.
-  Copyright (c) 2016 - 2020, Arm Limited. All rights reserved.
+  Copyright (c) 2016 - 2023, Arm Limited. All rights reserved.
   Copyright (c) 2022, AMD Incorporated. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 **/
@@ -202,6 +202,22 @@ Dump12Chars (
   IN   UINT8   *Ptr
   );
 
+/**
+  This function traces 16 characters which can be optionally
+  formated using the format string if specified.
+
+  If no format string is specified the Format must be NULL.
+
+  @param [in] Format  Optional format string for tracing the data.
+  @param [in] Ptr Pointer to the start of the buffer.
+**/
+VOID
+EFIAPI
+Dump16Chars (
+  IN CONST CHAR16  *Format OPTIONAL,
+  IN UINT8 *Ptr
+  );
+
 /**
   This function indents and prints the ACPI table Field Name.
 
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105131): https://edk2.groups.io/g/devel/message/105131
Mute This Topic: https://groups.io/mt/99066184/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V3 3/3] ShellPkg/AcpiView: Add MPAM Parser

[Rohit Mathew]

Add a parser for the MPAM (Memory system resource partitioning and
monitoring) ACPI table. This parser would parse all MPAM related
structures embedded as part of the ACPI table. Necessary validations are
also performed where and when required.

Signed-off-by: Rohit Mathew 
---
 ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h| 
  21 +
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Mpam/MpamParser.c   | 
1331 
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Mpam/MpamParser.h   | 
  25 +
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.c   | 
   3 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.inf | 
   4 +-
 ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.uni | 
   3 +-
 6 files changed, 1384 insertions(+), 3 deletions(-)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
index c9f41650d9..fef08e714d 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h
@@ -825,6 +825,27 @@ ParseAcpiMcfg (
   IN UINT8AcpiTableRevision
   );
 
+/**
+  This function parses the ACPI MPAM table.
+  When trace is enabled this function parses the MCFG table and
+  traces the ACPI table fields.
+
+  This function also performs validation of the ACPI table fields.
+
+  @param [in] Trace  If TRUE, trace the ACPI fields.
+  @param [in] PtrPointer to the start of the buffer.
+  @param [in] AcpiTableLengthLength of the ACPI table.
+  @param [in] AcpiTableRevision  Revision of the ACPI table.
+**/
+VOID
+EFIAPI
+ParseAcpiMpam (
+  IN BOOLEAN  Trace,
+  IN UINT8*Ptr,
+  IN UINT32   AcpiTableLength,
+  IN UINT8AcpiTableRevision
+  );
+
 /**
   This function parses the ACPI PCCT table including its sub-structures
   of type 0 through 4.
diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Mpam/MpamParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Mpam/MpamParser.c
new file mode 100644
index 00..9352357318
--- /dev/null
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Mpam/MpamParser.c
@@ -0,0 +1,1331 @@
+/** @file
+  MPAM table parser
+
+  Copyright (c) 2023, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Specification Reference:
+   - [1] ACPI for Memory System Resource Partitioning and Monitoring 2.0
+ (https://developer.arm.com/documentation/den0065/latest)
+
+  @par Glossary:
+- MPAM - Memory System Resource Partitioning And Monitoring
+- MSC  - Memory System Component
+- PCC  - Platform Communication Channel
+- RIS  - Resource Instance Selection
+- SMMU - Arm System Memory Management Unit
+ **/
+
+#include 
+#include 
+#include 
+#include "AcpiParser.h"
+#include "AcpiView.h"
+#include "AcpiViewConfig.h"
+#include "MpamParser.h"
+
+// Local variables
+STATIC UINT8 *Locator;
+STATIC CONST UINT8   *LocatorType;
+STATIC CONST UINT16  *MpamMscNodeLength;
+STATIC UINT32MpamMscNodeLengthCumulative;
+STATIC UINT32HeaderSize;
+STATIC CONST UINT32  *ErrorInterrupt;
+STATIC CONST UINT32  *InterfaceType;
+STATIC CONST UINT32  *NumberOfMscResources;
+STATIC CONST UINT32  *NumberOfFunctionalDependencies;
+STATIC CONST UINT32  *NumberOfInterconnectDescriptors;
+STATIC CONST UINT32  *OverflowInterrupt;
+STATIC ACPI_DESCRIPTION_HEADER_INFO  AcpiHdrInfo;
+
+/**
+  When the length of the table is insufficient to be parsed, this function 
could
+  be used to display an appropriate error message.
+
+  @param [in] ErrorMsg  Error message string that has to be appended to the
+  main error log. This string could explain the reason
+  why a insufficient length error was encountered in
+  the first place.
+**/
+STATIC
+VOID
+EFIAPI
+MpamLengthError (
+  IN CONST CHAR16  *ErrorMsg
+  )
+{
+  IncrementErrorCount ();
+  Print (L"\nERROR : ");
+  Print (ErrorMsg);
+  Print (
+L"\nError : Insufficient MPAM MSC Node length. Table length : %u.\n",
+*(AcpiHdrInfo.Length)
+);
+}
+
+/**
+  This function validates the passed reserved parameter. Any reserved field
+  within the MPAM specification must be 0.
+
+  @param [in] Reserved Reserved param that has to be validated.
+**/
+STATIC
+VOID
+EFIAPI
+ValidateReserved (
+  IN CONST UINT64  Reserved
+  )
+{
+  if (Reserved != 0) {
+IncrementErrorCount ();
+Print (L"\nERROR : Reserved field should be 0\n");
+  }
+}
+
+/**
+  This function validates reserved fields. Any reserved field within the MPAM
+  specification must be 0.
+
+  @param [in] Ptr   Pointer to the start of the field data.
+  @param [in] Con

Re: 回复: [edk2-devel] [PATCH] MdePkg Include: Fix typos

[Michael Kubacki]

In audit mode, it will not cause a build failure whether for new or 
existing code. It simply puts the results in the build log.


Note that "audit mode" is enabled on a per-package basis and some edk2 
packages have it disabled such as DynamicTablesPkg, FatPkg, 
FmpDevicePkg, PcAtChipsetPkg, PrmPkg, SourceLevelDebugPkg, and 
UnitTestFrameworkPkg.


I've made attempts in the past to bring additional packages out of audit 
mode but concern was raised about CI failing due to typos and false 
positives.


Work would need to be done to improve the maintainer experience such as 
updating cspell.base.yaml 
(https://github.com/tianocore/edk2/blob/master/.pytool/Plugin/SpellCheck/cspell.base.yaml) 
to extend more words common to the project and then packages should just 
need to make package-specific adjustments to the ignored words that may 
be specific to the package.


Spell check used in CI can be run locally, instructions are here - 
https://github.com/tianocore/tianocore.github.io/wiki/How-to-Build-With-Stuart#i-want-to-fix-all-the-spelling-errors-in-my-package-how-do-i-just-run-the-spell-check-plugin.


On 5/21/2023 9:14 PM, gaoliming via groups.io wrote:

Michael:
   That means CSpell force check is only for new added code, not for all 
existing code. Right?

Thanks
Liming

-邮件原件-
发件人: devel@edk2.groups.io  代表 Giri
Mudusuru via groups.io
发送时间: 2023年5月21日 10:41
收件人: Michael Kubacki 
抄送: devel@edk2.groups.io; gaoliming ;
Michael D Kinney ; Zhiguang Liu
; Andrew Fish ; Giri Mudusuru

主题: Re: [edk2-devel] [PATCH] MdePkg Include: Fix typos

Thanks Michael for below info.



On May 18, 2023, at 8:36 AM, Michael Kubacki

 wrote:


The spell check CI plugin is in "AuditOnly" mode so it is not actually failing

the build.




https://github.com/tianocore/edk2/blob/master/MdePkg/MdePkg.ci.yaml#L
166


This has more info about how to configure the plugin in each package CI

YAML file -
https://github.com/tianocore/edk2/tree/master/.pytool/Plugin/SpellCheck.


If you go to a CI build of MdePkg like:



https://dev.azure.com/tianocore/edk2-ci/_build/results?buildId=91890&view
=artifacts&pathAsName=false&type=publishedArtifacts


And download the "Build Logs TARGET_MDE_CPU" log (ellipsis on the right

then "Download artifacts"). Search that for "Unknown word" and you'lll get
many issues - in that log 7,505 hits. That includes duplicates of the same word.


On 5/17/2023 2:20 PM, Giri Mudusuru via groups.io wrote:

Hi Liming,
Most of the errors except below macro are in comments. Not sure if CI

SpellCheck is skipping comments?

I can revert the macro fix from this patch. I noticed that it is duplicated in

Acpi.h and Acpi10.h.

Thanks,
-Giri

On May 16, 2023, at 6:49 AM, gaoliming 

wrote:


Giri:
Edk2 CI enables SpellCheck. Seemly, those typos are not detected by CI.

So, I want to confirm which tool do you use.


This patch is good. But, the first changes the existing MACRO name. I am

not sure whether there is any code impact.


Thanks
Liming

-邮件原件-
发件人: Giri Mudusuru 
发送时间: 2023年5月15日 10:49
收件人: gaoliming 
抄送: devel@edk2.groups.io; Michael D Kinney
; Zhiguang Liu ;
Andrew Fish ; Giri Mudusuru 
主题: Re: [PATCH] MdePkg Include: Fix typos

Hi Liming,

These typos are found during reviews, sync with open source and other

debug.

Just kept running list and then a simple search and replace in repo.

I have fix for other packages too, just starting with MdePkg to get some
feedback on size of patch (number of files etc)

I am using VS Code IDE with Code Spell Checker plugin which highlights

any

typos.

Thanks,
-Giri


On May 15, 2023, at 7:10 AM, gaoliming 

wrote:


Giri:
How do you find these typos? Which tool do you use to scan the code?

Thanks
Liming

-邮件原件-
发件人: Giri Mudusuru 
发送时间: 2023年5月12日 18:25
收件人: devel@edk2.groups.io
抄送: Giri Mudusuru ; Michael D Kinney
; Liming Gao

;

Zhiguang Liu ; Andrew Fish



主题: [PATCH] MdePkg Include: Fix typos

compatability->compatibility
EFI_MEDIA_CHNAGED->EFI_MEDIA_CHANGED
Funtion->Function
exhausive->exhaustive
Propery->Property
StartAdress->StartAddress
sucessful->successful
writting->writing

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Andrew Fish 
Signed-off-by: Giri Mudusuru 
---
MdePkg/Include/IndustryStandard/Acpi10.h  |  2 +-
MdePkg/Include/Library/DebugLib.h | 50
+--
MdePkg/Include/Library/PerformanceLib.h   |  2 +-
MdePkg/Include/Library/PostCodeLib.h  | 12 ++---
MdePkg/Include/Library/ReportStatusCodeLib.h  | 26 +-
MdePkg/Include/Library/S3PciLib.h |  4 +-
MdePkg/Include/Library/S3PciSegmentLib.h  |  4 +-
MdePkg/Include/Library/UefiLib.h  |  2 +-
MdePkg/Include/Protocol/BlockIo.h |  4 +-
MdePkg/Include/Protocol/BlockIo2.h|  6 +--
MdePkg/Include/Protocol/BlockIoCrypto.h   |  2 +-
MdePkg/Include/Protocol/DiskIo.h  |  4 +-
MdePkg/Include/Protocol/DiskIo2.h |  6 +--
MdePkg/Include/Protocol/Ip4.h

Re: [edk2-devel] [PATCH] IntelFsp2WrapperPkg: Fix ASSERT when FSP-S/M use FFS3

[Chiu, Chasel]

Reviewed-by: Chasel Chiu 

Thanks,
Chasel


> -Original Message-
> From: Tan, Ming 
> Sent: Sunday, May 21, 2023 11:13 PM
> To: devel@edk2.groups.io
> Cc: Chiu, Chasel ; Duggapu, Chinni B
> 
> Subject: [PATCH] IntelFsp2WrapperPkg: Fix ASSERT when FSP-S/M use FFS3
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4458
> 
> Original code call PeiServicesInstallFvInfoPpi() with NULL for the FvFormat
> parameter, then PeiServicesInstallFvInfoPpi() will assume it use FFS2, then
> ASSERT if FSP-S/M use FFS3.
> Now set the FvFormat to the info got from FvHeader.
> 
> Cc: Chasel Chiu 
> Cc: Duggapu Chinni B 
> Signed-off-by: Ming Tan 
> ---
>  IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c | 2 +-
> IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> index ea206a7960..ba0c742fea 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
> @@ -217,7 +217,7 @@ FspmWrapperInit (
>  ASSERT_EFI_ERROR (Status);  PeiServicesInstallFvInfoPpi (-  
> NULL,+
> &((EFI_FIRMWARE_VOLUME_HEADER *)(UINTN)PcdGet32
> (PcdFspmBaseAddress))->FileSystemGuid,   (VOID *)(UINTN)PcdGet32
> (PcdFspmBaseAddress),   (UINT32)((EFI_FIRMWARE_VOLUME_HEADER
> *)(UINTN)PcdGet32 (PcdFspmBaseAddress))->FvLength,   NULL,diff --git
> a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> index 091ddb697a..08fe0fdb7e 100644
> --- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> +++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
> @@ -438,7 +438,7 @@ FspsWrapperInitDispatchMode (
>// FSP-S Wrapper running in Dispatch mode and reports FSP-S FV to PEI
> dispatcher.   //   PeiServicesInstallFvInfoPpi (-NULL,+
> &((EFI_FIRMWARE_VOLUME_HEADER *)(UINTN)PcdGet32
> (PcdFspsBaseAddress))->FileSystemGuid, (VOID *)(UINTN)PcdGet32
> (PcdFspsBaseAddress), (UINT32)((EFI_FIRMWARE_VOLUME_HEADER
> *)(UINTN)PcdGet32 (PcdFspsBaseAddress))->FvLength, NULL,--
> 2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105134): https://edk2.groups.io/g/devel/message/105134
Mute This Topic: https://groups.io/mt/99059532/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-stable202305] ArmPkg/ArmMmuLib: Add missing ISB after page table update

[Ard Biesheuvel]

PR here: https://github.com/tianocore/edk2/pull/4418

I cannot set the 'push' label myself, it seems.



On Mon, 22 May 2023 at 16:10, Kinney, Michael D
 wrote:
>
> Acked-by: Michael D Kinney 
>
> No objection to merging for the stable tag.
>
> Mike
>
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Leif
> > Lindholm
> > Sent: Monday, May 22, 2023 3:56 AM
> > To: Ard Biesheuvel 
> > Cc: devel@edk2.groups.io; Gao, Liming ;
> > Kinney, Michael D ; Oliver Steffen
> > 
> > Subject: Re: [edk2-devel] [PATCH edk2-stable202305] ArmPkg/ArmMmuLib:
> > Add missing ISB after page table update
> >
> > On Sat, May 20, 2023 at 11:19:58 +0200, Ard Biesheuvel wrote:
> > > The helper that updates live page table entries writes a zero entry,
> > > invalidates the covered address range from the TLBs, and finally writes
> > > the actual entry. This ensures that no TLB conflicts can occur.
> > >
> > > Writing the final entry needs to complete before any translations can be
> > > performed, as otherwise, the zero entry, which describes an invalid
> > > translation, may be observed by the page table walker, resulting in a
> > > translation fault. For this reason, the final write is followed by a DSB
> > > barrier instruction.
> > >
> > > However, this barrier will not stall the pipeline, and instruction
> > > fetches may still hit this invalid translation, as has been observed and
> > > reported by Oliver. To ensure that the new translation is fully active
> > > before returning from this helper, we have to insert an ISB barrier as
> > > well.
> > >
> > > Cc: Liming Gao 
> > > Cc: Leif Lindholm 
> > > Cc: Michael D Kinney 
> > > Reported-by: Oliver Steffen 
> > > Tested-by: Oliver Steffen 
> > > Signed-off-by: Ard Biesheuvel 
> >
> > Reviewed-by: Leif Lindholm 
> >
> > We need this in the stable tag.
> >
> > Note: the isb instruction forces the synchronization of certain
> > architectural events. It has no other effects. I.e., any issues
> > exposed by this addition would already have been present before it.
> >
> > As such, I would suggest this addition need *not* affect the stable
> > tag schedule.
> >
> > /
> > Leif
> >
> > > ---
> > >  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git
> > a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > > index 887439bc042f0f16..1f0d8057926933d7 100644
> > > --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > > +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > > @@ -65,6 +65,7 @@
> > >// write updated entry
> > >str   x1, [x0]
> > >dsb   nshst
> > > +  isb
> > >
> > >  .L2_\@:
> > >.endm
> > > --
> > > 2.39.2
> > >
> >
> >
> > 
> >
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105135): https://edk2.groups.io/g/devel/message/105135
Mute This Topic: https://groups.io/mt/99027974/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Event: Tools, CI, Code base construction meeting series - Monday, May 22, 2023 #cal-reminder

[Group Notification]

*Reminder: Tools, CI, Code base construction meeting series*

*When:*
Monday, May 22, 2023
4:30pm to 5:30pm
(UTC-07:00) America/Los Angeles

*Where:*
https://github.com/tianocore/edk2/discussions/2614

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=1890535 )

*Description:*

TianoCore community,

Microsoft and Intel will be hosting a series of open meetings to discuss build, 
CI, tools, and other related topics. If you are interested, have ideas/opinions 
please join us. These meetings will be Monday 4:30pm Pacific Time on Microsoft 
Teams.

MS Teams Link in following discussion: * 
https://github.com/tianocore/edk2/discussions/2614

Anyone is welcome to join.

* tianocore/edk2: EDK II (github.com)
* tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP module 
(github.com) https://github.com/tianocore/edk2-basetools
* tianocore/edk2-pytool-extensions: Extensions to the edk2 build system 
allowing for a more robust and plugin based build system and tool execution 
environment (github.com) https://github.com/tianocore/edk2-pytool-extensions
* tianocore/edk2-pytool-library: Python library package that supports UEFI 
development (github.com) https://github.com/tianocore/edk2-pytool-library

MS Teams Browser Clients * 
https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105136): https://edk2.groups.io/g/devel/message/105136
Mute This Topic: https://groups.io/mt/99055445/21656
Mute #cal-reminder:https://edk2.groups.io/g/devel/mutehashtag/cal-reminder
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] managing memory attributes in PEI

[Ni, Ray]

Gerd,
The S3 path has been 64bit ready.
Can you check if OVMF pei64 image can do s3?

At least internally in some real platform we tested s3 flow with 64bit PEI.

Thanks,
Ray

thanks,
ray

From: Gerd Hoffmann 
Sent: Monday, May 22, 2023 8:06:46 PM
To: Ard Biesheuvel 
Cc: edk2-devel-groups-io ; Ni, Ray ; 
Yao, Jiewen ; Laszlo Ersek ; Taylor 
Beebe ; Oliver Smith-Denny 
Subject: Re: managing memory attributes in PEI

> So my questions are:
> - do we need to retain mixed IA32 / X64 support, and if so, why? (I
> think it is related to SMM emulation but I need someone to confirm
> this)

Yes, it's SMM related.  S3 suspend in SMM-enabled builds requires
32bit PEI.

Intel seems to be working on removing the IA32 dependency, by adding
full X64 support to various places in the code base.  There have been
numerous patch sets on the list over the last months, some of them
are merged meanwhile.  As far I know the patch series addressing the
suspend problem is not yet merged (Ray, Jiewen, please correct me if
I'm wrong).

So, right now we still need that, but I expect that to change in near
future.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105137): https://edk2.groups.io/g/devel/message/105137
Mute This Topic: https://groups.io/mt/99062463/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Now: Tools, CI, Code base construction meeting series - Monday, May 22, 2023 #cal-notice

[Group Notification]

*Tools, CI, Code base construction meeting series*

*When:*
Monday, May 22, 2023
4:30pm to 5:30pm
(UTC-07:00) America/Los Angeles

*Where:*
https://github.com/tianocore/edk2/discussions/2614

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=1890535 )

*Description:*

TianoCore community,

Microsoft and Intel will be hosting a series of open meetings to discuss build, 
CI, tools, and other related topics. If you are interested, have ideas/opinions 
please join us. These meetings will be Monday 4:30pm Pacific Time on Microsoft 
Teams.

MS Teams Link in following discussion: * 
https://github.com/tianocore/edk2/discussions/2614

Anyone is welcome to join.

* tianocore/edk2: EDK II (github.com)
* tianocore/edk2-basetools: EDK II BaseTools Python tools as a PIP module 
(github.com) https://github.com/tianocore/edk2-basetools
* tianocore/edk2-pytool-extensions: Extensions to the edk2 build system 
allowing for a more robust and plugin based build system and tool execution 
environment (github.com) https://github.com/tianocore/edk2-pytool-extensions
* tianocore/edk2-pytool-library: Python library package that supports UEFI 
development (github.com) https://github.com/tianocore/edk2-pytool-library

MS Teams Browser Clients * 
https://docs.microsoft.com/en-us/microsoftteams/get-clients?tabs=Windows#browser-client


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105138): https://edk2.groups.io/g/devel/message/105138
Mute This Topic: https://groups.io/mt/99076955/21656
Mute #cal-notice:https://edk2.groups.io/g/devel/mutehashtag/cal-notice
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-stable202305] ArmPkg/ArmMmuLib: Add missing ISB after page table update

[Michael D Kinney]

I have set push label.  It is merged now.

During hard freeze, the release owner and stewards are the only once that can 
set the label.

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ard
> Biesheuvel
> Sent: Monday, May 22, 2023 9:19 AM
> To: Kinney, Michael D 
> Cc: devel@edk2.groups.io; quic_llind...@quicinc.com; Gao, Liming
> ; Oliver Steffen 
> Subject: Re: [edk2-devel] [PATCH edk2-stable202305] ArmPkg/ArmMmuLib:
> Add missing ISB after page table update
> 
> PR here: https://github.com/tianocore/edk2/pull/4418
> 
> I cannot set the 'push' label myself, it seems.
> 
> 
> 
> On Mon, 22 May 2023 at 16:10, Kinney, Michael D
>  wrote:
> >
> > Acked-by: Michael D Kinney 
> >
> > No objection to merging for the stable tag.
> >
> > Mike
> >
> > > -Original Message-
> > > From: devel@edk2.groups.io  On Behalf Of Leif
> > > Lindholm
> > > Sent: Monday, May 22, 2023 3:56 AM
> > > To: Ard Biesheuvel 
> > > Cc: devel@edk2.groups.io; Gao, Liming ;
> > > Kinney, Michael D ; Oliver Steffen
> > > 
> > > Subject: Re: [edk2-devel] [PATCH edk2-stable202305]
> ArmPkg/ArmMmuLib:
> > > Add missing ISB after page table update
> > >
> > > On Sat, May 20, 2023 at 11:19:58 +0200, Ard Biesheuvel wrote:
> > > > The helper that updates live page table entries writes a zero entry,
> > > > invalidates the covered address range from the TLBs, and finally writes
> > > > the actual entry. This ensures that no TLB conflicts can occur.
> > > >
> > > > Writing the final entry needs to complete before any translations can
> be
> > > > performed, as otherwise, the zero entry, which describes an invalid
> > > > translation, may be observed by the page table walker, resulting in a
> > > > translation fault. For this reason, the final write is followed by a DSB
> > > > barrier instruction.
> > > >
> > > > However, this barrier will not stall the pipeline, and instruction
> > > > fetches may still hit this invalid translation, as has been observed and
> > > > reported by Oliver. To ensure that the new translation is fully active
> > > > before returning from this helper, we have to insert an ISB barrier as
> > > > well.
> > > >
> > > > Cc: Liming Gao 
> > > > Cc: Leif Lindholm 
> > > > Cc: Michael D Kinney 
> > > > Reported-by: Oliver Steffen 
> > > > Tested-by: Oliver Steffen 
> > > > Signed-off-by: Ard Biesheuvel 
> > >
> > > Reviewed-by: Leif Lindholm 
> > >
> > > We need this in the stable tag.
> > >
> > > Note: the isb instruction forces the synchronization of certain
> > > architectural events. It has no other effects. I.e., any issues
> > > exposed by this addition would already have been present before it.
> > >
> > > As such, I would suggest this addition need *not* affect the stable
> > > tag schedule.
> > >
> > > /
> > > Leif
> > >
> > > > ---
> > > >  ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S | 1
> +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git
> > > a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > > b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > > > index 887439bc042f0f16..1f0d8057926933d7 100644
> > > > --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > > > +++
> b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibReplaceEntry.S
> > > > @@ -65,6 +65,7 @@
> > > >// write updated entry
> > > >str   x1, [x0]
> > > >dsb   nshst
> > > > +  isb
> > > >
> > > >  .L2_\@:
> > > >.endm
> > > > --
> > > > 2.39.2
> > > >
> > >
> > >
> > >
> > >
> >
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105139): https://edk2.groups.io/g/devel/message/105139
Mute This Topic: https://groups.io/mt/99027974/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, May 23, 2023 #cal-reminder

[Group Notification]

*Reminder: TianoCore Bug Triage - APAC / NAMO*

*When:*
Tuesday, May 23, 2023
6:30pm to 7:30pm
(UTC-07:00) America/Los Angeles

*Where:*
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d

*Organizer:* Liming Gao gaolim...@byosoft.com.cn ( 
gaolim...@byosoft.com.cn?subject=Re:%20Event:%20TianoCore%20Bug%20Triage%20-%20APAC%20%2F%20NAMO
 )

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=1890530 )

*Description:*

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao



Microsoft Teams meeting

*Join on your computer or mobile app*

Click here to join the meeting ( 
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d
 )

*Join with a video conferencing device*

te...@conf.intel.com

Video Conference ID: 116 062 094 0

Alternate VTC dialing instructions ( 
https://conf.intel.com/teams/?conf=1160620940&ivr=teams&d=conf.intel.com&test=test_call
 )

*Or call in (audio only)*

+1 916-245-6934,,77463821# ( tel:+19162456934,,77463821# ) United States, 
Sacramento

Phone Conference ID: 774 638 21#

Find a local number ( 
https://dialin.teams.microsoft.com/d195d438-2daa-420e-b9ea-da26f9d1d6d5?id=77463821
 ) | Reset PIN ( https://mysettings.lync.com/pstnconferencing )

Learn More ( https://aka.ms/JoinTeamsMeeting ) | Meeting options ( 
https://teams.microsoft.com/meetingOptions/?organizerId=b286b53a-1218-4db3-bfc9-3d4c5aa7669e&tenantId=46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_OTUyZTg2NjgtNDhlNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh@thread.v2&messageId=0&language=en-US
 )


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105140): https://edk2.groups.io/g/devel/message/105140
Mute This Topic: https://groups.io/mt/99078847/21656
Mute #cal-reminder:https://edk2.groups.io/g/devel/mutehashtag/cal-reminder
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] GoogleTest Compatibility with MdePkg's IndustyStandard header files

[Aaron Pop via groups.io]

Google Test, and CPP, has more keywords  C uses.

Tpm12.h and Tpm20.h have references to struct names that are `operator` and 
`xor`, both of which trigger build errors because they conflict with CPP's 
keywords.

Operator triggered a build error in MSVC. Xor only triggered a build error 
under GCC, MSVC did not have a problem with it.

The work arounds suggested in the call, (using defines to get around the 
conflict) worked for operator, but did not work for xor with gcc.


Tpm12.h:
TPM_PERMANENT_FLAGS
  BOOLEAN   operator;


Tpm20.h:
TPMU_SCHEME_KEYEDHASH
  TPMS_SCHEME_XOR  xor;

TPMU_SYM_KEY_BITS
  TPMI_ALG_HASH xor;


What is the suggested method of trying to make existing header files compatible 
with google test?

Thanks,
Aaron


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105141): https://edk2.groups.io/g/devel/message/105141
Mute This Topic: https://groups.io/mt/99079638/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1] StandaloneMmPkg: Add StandaloneMmIplPei driver.

[Zhang, Hongbin1]

Add StandaloneMmIplPei IA32/X64 driver at PEI stage.
FSP will use this driver to load Standalone MM code
to dispatch other Standalone MM drivers.

Signed-off-by: Hongbin1 Zhang 
Cc: Jiewen Yao 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Jiaxin Wu 
Cc: Sami Mujawar 
Cc: Ard Biesheuvel 
Cc: Supreeth Venkatesh 
---
 StandaloneMmPkg/Drivers/StandaloneMmIplPei/Ia32/LoadSmmCore.c | 456 

 StandaloneMmPkg/Drivers/StandaloneMmIplPei/StandaloneMmIplPei.c   | 787 

 StandaloneMmPkg/Drivers/StandaloneMmIplPei/X64/LoadSmmCore.c  |  32 +
 StandaloneMmPkg/Drivers/StandaloneMmIplPei/Ia32/Thunk32To64.nasm  | 148 
 StandaloneMmPkg/Drivers/StandaloneMmIplPei/StandaloneMmIplPei.h   |  66 ++
 StandaloneMmPkg/Drivers/StandaloneMmIplPei/StandaloneMmIplPei.inf |  75 ++
 StandaloneMmPkg/StandaloneMmPkg.ci.yaml   |   4 +-
 StandaloneMmPkg/StandaloneMmPkg.dsc   |  15 +-
 UefiPayloadPkg/UniversalPayloadBuild.sh   |  34 +-
 edksetup.sh   | 294 

 10 files changed, 1744 insertions(+), 167 deletions(-)

diff --git a/StandaloneMmPkg/Drivers/StandaloneMmIplPei/Ia32/LoadSmmCore.c 
b/StandaloneMmPkg/Drivers/StandaloneMmIplPei/Ia32/LoadSmmCore.c
new file mode 100644
index 00..d6174d73a3
--- /dev/null
+++ b/StandaloneMmPkg/Drivers/StandaloneMmIplPei/Ia32/LoadSmmCore.c
@@ -0,0 +1,456 @@
+/** @file
+  SMM IPL that load the SMM Core into SMRAM
+
+  Copyright (c) 2023, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#pragma pack(1)
+
+//
+// Page-Map Level-4 Offset (PML4) and
+// Page-Directory-Pointer Offset (PDPE) entries 4K & 2MB
+//
+
+typedef union {
+  struct {
+UINT64Present  : 1;   // 0 = Not present in memory, 1 = 
Present in memory
+UINT64ReadWrite: 1;   // 0 = Read-Only, 1= Read/Write
+UINT64UserSupervisor   : 1;   // 0 = Supervisor, 1=User
+UINT64WriteThrough : 1;   // 0 = Write-Back caching, 
1=Write-Through caching
+UINT64CacheDisabled: 1;   // 0 = Cached, 1=Non-Cached
+UINT64Accessed : 1;   // 0 = Not accessed, 1 = Accessed 
(set by CPU)
+UINT64Reserved : 1;   // Reserved
+UINT64MustBeZero   : 2;   // Must Be Zero
+UINT64Available: 3;   // Available for use by system 
software
+UINT64PageTableBaseAddress : 40;  // Page Table Base Address
+UINT64AvailableHigh: 11;  // Available for use by system 
software
+UINT64Nx   : 1;   // No Execute bit
+  } Bits;
+  UINT64Uint64;
+} PAGE_MAP_AND_DIRECTORY_POINTER;
+
+//
+// Page Table Entry 2MB
+//
+typedef union {
+  struct {
+UINT64Present  : 1;   // 0 = Not present in memory, 1 = 
Present in memory
+UINT64ReadWrite: 1;   // 0 = Read-Only, 1= Read/Write
+UINT64UserSupervisor   : 1;   // 0 = Supervisor, 1=User
+UINT64WriteThrough : 1;   // 0 = Write-Back caching, 
1=Write-Through caching
+UINT64CacheDisabled: 1;   // 0 = Cached, 1=Non-Cached
+UINT64Accessed : 1;   // 0 = Not accessed, 1 = Accessed 
(set by CPU)
+UINT64Dirty: 1;   // 0 = Not Dirty, 1 = written by 
processor on access to page
+UINT64MustBe1  : 1;   // Must be 1
+UINT64Global   : 1;   // 0 = Not global page, 1 = global 
page TLB not cleared on CR3 write
+UINT64Available: 3;   // Available for use by system 
software
+UINT64Pat  : 1;   //
+UINT64MustBeZero   : 8;   // Must be zero
+UINT64PageTableBaseAddress : 31;  // Page Table Base Address
+UINT64AvailableHigh: 11;  // Available for use by system 
software
+UINT64Nx   : 1;   // 0 = Execute Code, 1 = No Code 
Execution
+  } Bits;
+  UINT64Uint64;
+} PAGE_TABLE_ENTRY;
+
+//
+// Page Table Entry 1GB
+//
+typedef union {
+  struct {
+UINT64Present  : 1;   // 0 = Not present in memory, 1 = 
Present in memory
+UINT64ReadWrite: 1;   // 0 = Read-Only, 1= Read/Write
+UINT64UserSupervisor   : 1;   // 0 = Supervisor, 1=User
+UINT64WriteThrough : 1;   // 0 = Write-Back caching, 
1=Write-Through caching
+UINT64CacheDisabled: 1;   // 0 = Cached, 1=Non-Cached
+UINT64Accessed : 1;   // 0 = Not accessed, 1 = Accessed 
(set by CPU)
+UINT64Dirty: 1;   // 0 = Not Dirty, 1 = written by 
processor on access to page
+UINT64MustBe1  : 1;   // Must be 1
+UINT64Global   : 1;   // 0 = Not global page, 1 = global 
page TLB not cleared on CR3 write

Re: [edk2-devel] managing memory attributes in PEI

[Gerd Hoffmann]

On Mon, May 22, 2023 at 11:20:16PM +, Ni, Ray wrote:
> Gerd,
> The S3 path has been 64bit ready.
> Can you check if OVMF pei64 image can do s3?
> 
> At least internally in some real platform we tested s3 flow with 64bit PEI.

Tested on OVMF, passed too.

Which are the commits implementing this?  I'd like the reference them in
the commit message for S3Verification() removal.

thanks,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105143): https://edk2.groups.io/g/devel/message/105143
Mute This Topic: https://groups.io/mt/99062463/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] managing memory attributes in PEI

[Laszlo Ersek]

On 5/22/23 13:31, Ard Biesheuvel wrote:
> Hello all,
> 
> (OVMF specific questions below - please keep reading)
> 
> As a follow-up to the discussion we had last week regarding DXE core,
> I'd like to raise the issue of managing memory permissions in PEI,
> including the mapping attributes of the code and data regions of DXE
> core itself.
> 
> This is about good hygiene in general, but on arm64 in particular,
> limiting execution permissions to memory regions that are mapped
> read-only allows the MMU to be enabled in WXN mode, where all writable
> regions are non-executable by default.
> 
> I have implemented a proof-of-concept of this for ArmVirtQemu and
> Raspberry Pi 4 (the former using PEI and the latter PEI-less), and
> this seems quite feasible in practice, but there are a few issues that
> I have identified:
> 
> - PEI shadowing is currently disabled entirely - this is actually an
> advantage for the [virtual] platform in question, given that shadowing
> is more work for no benefit, but it is something that needs to be
> addressed in the general case;
> - no generic method exists to manage page table permissions.
> 
> So what I would like to propose (and what I intend to prototype) is a
> PPI that abstracts this capability, and which can be used by the PEI
> image loader as well as the DxeIpl to manage read-only and non-exec
> permissions. Most PEIMs only have a code region anyway, so hopefully
> there is some room for optimization where not all PEIMs need 4k
> alignment.
> 
> That leaves one big issue, and this is related to OVMF's use of IA32
> PEI with X64 DXE. This complicates the DxeIpl substantially already,
> but would make this effort rather tricky as well.
> 
> So my questions are:
> - do we need to retain mixed IA32 / X64 support, and if so, why? (I
> think it is related to SMM emulation but I need someone to confirm
> this)

For a long time, IA32X64 had been required if you wanted (a) X64 DXE,
(b) SMM, and (c) ACPI S3 resume. The reason was that
UefiCpuPkg/Universal/Acpi/S3Resume2Pei didn't support SMM on X64, only
on IA32.

See commit 5133d1f1d297 ("OvmfPkg: replace README fine print about X64
SMM S3 with PlatformPei check", 2015-11-30).

This S3Resume2Pei limitation got lifted last year, in commit
6acf72901a2e ("UefiCpuPkg: Supporting S3 in 64bit PEI", 2022-12-19), for
.

Gerd tested the according removal of S3Verification() in OVMF
, but that code
is not upstream (or downstream at that, IIUC), yet.

Once S3Verification() is removed, OVMF IA32X64 will remain useful for
exercising a particular IA32X64 combination of modules that physical
platforms use, but I reckon IA32X64 will no longer be required for
virtualization purposes per se.

Before we enabled SMM for OVMF, we had never really used IA32X64 OVMF --
SMM-less ACPI S3 resume had just worked fine with X64-only OVMF. IA32X64
only proved a great platform option to fall back to, when we realized
that on X64 OVMF, ACPI S3 resume wouldn't just seamlessly extend to SMM.

Thanks,
Laszlo

> - if we need to retain it, could we run PEI in long mode but with
> 32-bit compatibility enabled, so that we don't need two or three
> incompatible sets of page tables?
> 
> In the latter case, the PPI in question would carry the same logic for
> IA32 and X64 builds, and create 4-level page tables with the code
> still being 32-bit.
> 
> Once we clear this up, I'm happy to look into extending my prototype
> to x86 as well.
> 
> Thanks,
> Ard.
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105144): https://edk2.groups.io/g/devel/message/105144
Mute This Topic: https://groups.io/mt/99062463/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] managing memory attributes in PEI

[Ni, Ray]

> -Original Message-
> From: Laszlo Ersek 
> Sent: Tuesday, May 23, 2023 1:31 PM
> To: Ard Biesheuvel ; edk2-devel-groups-io
> ; Ni, Ray ; Yao, Jiewen
> ; Gerd Hoffmann ; Taylor Beebe
> ; Oliver Smith-Denny 
> Subject: Re: managing memory attributes in PEI
> 
> On 5/22/23 13:31, Ard Biesheuvel wrote:
> > Hello all,
> >
> > (OVMF specific questions below - please keep reading)
> >
> > As a follow-up to the discussion we had last week regarding DXE core,
> > I'd like to raise the issue of managing memory permissions in PEI,
> > including the mapping attributes of the code and data regions of DXE
> > core itself.
> >
> > This is about good hygiene in general, but on arm64 in particular,
> > limiting execution permissions to memory regions that are mapped
> > read-only allows the MMU to be enabled in WXN mode, where all writable
> > regions are non-executable by default.
> >
> > I have implemented a proof-of-concept of this for ArmVirtQemu and
> > Raspberry Pi 4 (the former using PEI and the latter PEI-less), and
> > this seems quite feasible in practice, but there are a few issues that
> > I have identified:
> >
> > - PEI shadowing is currently disabled entirely - this is actually an
> > advantage for the [virtual] platform in question, given that shadowing
> > is more work for no benefit, but it is something that needs to be
> > addressed in the general case;
> > - no generic method exists to manage page table permissions.
> >
> > So what I would like to propose (and what I intend to prototype) is a
> > PPI that abstracts this capability, and which can be used by the PEI
> > image loader as well as the DxeIpl to manage read-only and non-exec
> > permissions. Most PEIMs only have a code region anyway, so hopefully
> > there is some room for optimization where not all PEIMs need 4k
> > alignment.
> >
> > That leaves one big issue, and this is related to OVMF's use of IA32
> > PEI with X64 DXE. This complicates the DxeIpl substantially already,
> > but would make this effort rather tricky as well.
> >
> > So my questions are:
> > - do we need to retain mixed IA32 / X64 support, and if so, why? (I
> > think it is related to SMM emulation but I need someone to confirm
> > this)
> 
> For a long time, IA32X64 had been required if you wanted (a) X64 DXE,
> (b) SMM, and (c) ACPI S3 resume. The reason was that
> UefiCpuPkg/Universal/Acpi/S3Resume2Pei didn't support SMM on X64, only
> on IA32.
> 
> See commit 5133d1f1d297 ("OvmfPkg: replace README fine print about X64
> SMM S3 with PlatformPei check", 2015-11-30).
> 
> This S3Resume2Pei limitation got lifted last year, in commit
> 6acf72901a2e ("UefiCpuPkg: Supporting S3 in 64bit PEI", 2022-12-19), for
> .
> 
> Gerd tested the according removal of S3Verification() in OVMF
> , but that code
> is not upstream (or downstream at that, IIUC), yet.
> 
> Once S3Verification() is removed, OVMF IA32X64 will remain useful for
> exercising a particular IA32X64 combination of modules that physical
> platforms use, but I reckon IA32X64 will no longer be required for
> virtualization purposes per se.

Wow. I didn't realize OVMF had S3Verification() to explicitly educate users
X64 PEI + SMM doesn't support S3.:)
That will be great to remove the code today.

> 
> Before we enabled SMM for OVMF, we had never really used IA32X64 OVMF --
> SMM-less ACPI S3 resume had just worked fine with X64-only OVMF. IA32X64
> only proved a great platform option to fall back to, when we realized
> that on X64 OVMF, ACPI S3 resume wouldn't just seamlessly extend to SMM.

I don't quite understand. So, what's the conclusion of IA32X64 OVMF? Keep it? 
Remove it?



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105145): https://edk2.groups.io/g/devel/message/105145
Mute This Topic: https://groups.io/mt/99062463/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] managing memory attributes in PEI

[Laszlo Ersek]

On 5/22/23 14:06, Gerd Hoffmann wrote:
>> So my questions are:
>> - do we need to retain mixed IA32 / X64 support, and if so, why? (I
>> think it is related to SMM emulation but I need someone to confirm
>> this)
> 
> Yes, it's SMM related.  S3 suspend in SMM-enabled builds requires
> 32bit PEI.
> 
> Intel seems to be working on removing the IA32 dependency, by adding
> full X64 support to various places in the code base.  There have been
> numerous patch sets on the list over the last months, some of them
> are merged meanwhile.  As far I know the patch series addressing the
> suspend problem is not yet merged (Ray, Jiewen, please correct me if
> I'm wrong).

You've forgotten about our discussion in 
 :)

> So, right now we still need that, but I expect that to change in near
> future.

BTW just last evening I found out about X86-S:

- https://www.phoronix.com/news/Intel-X86-S-64-bit-Only
- 
https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
- https://cdrdv2.intel.com/v1/dl/getContent/776648

I'm slightly curious if those IA32->X64 "replacement" patches you mention are 
related to X86-S ;)

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105146): https://edk2.groups.io/g/devel/message/105146
Mute This Topic: https://groups.io/mt/99062463/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] managing memory attributes in PEI

[Laszlo Ersek]

On 5/23/23 06:49, Gerd Hoffmann wrote:
> On Mon, May 22, 2023 at 11:20:16PM +, Ni, Ray wrote:
>> Gerd,
>> The S3 path has been 64bit ready.
>> Can you check if OVMF pei64 image can do s3?
>>
>> At least internally in some real platform we tested s3 flow with 64bit PEI.
> 
> Tested on OVMF, passed too.
> 
> Which are the commits implementing this?  I'd like the reference them in
> the commit message for S3Verification() removal.

commit 6acf72901a2e / bug 4195, AFAIK; there could be other related
commits since I last looked, of course



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105147): https://edk2.groups.io/g/devel/message/105147
Mute This Topic: https://groups.io/mt/99062463/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] managing memory attributes in PEI

[Ni, Ray]

Revision: 8bd2028f9ac391144c67eaf6eb08c3f727c32498
Author: Kuo, Ted 
Date: 12/16/2022 8:46:27 PM
Message:
MdeModulePkg: Supporting S3 in 64bit PEI

https://bugzilla.tianocore.org/show_bug.cgi?id=4195
Transfer from DXE to OS waking vector by calling SwitchStack() when
both are in the same execution mode.

Reviewed-by: Ray Ni 
Reviewed-by: Zhiguang Liu 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Star Zeng 
Cc: Ashraf Ali S 
Cc: Chinni B Duggapu 
Signed-off-by: Ted Kuo 

Modified: MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/ScriptExecute.c
Modified: MdeModulePkg/Universal/Acpi/BootScriptExecutorDxe/X64/SetIdtEntry.c
Modified: MdeModulePkg/Universal/Acpi/S3SaveStateDxe/AcpiS3ContextSave.c

Revision: 6acf72901a2e811a2838cafd496239a34779066a
Author: Kuo, Ted 
Date: 12/16/2022 8:46:26 PM
Message:
UefiCpuPkg: Supporting S3 in 64bit PEI

https://bugzilla.tianocore.org/show_bug.cgi?id=4195
1.Updated the GDT table in VTF0 to align with the one in S3Resume2Pei.
  By doing so can simplify the changes to enable S3 in 64bit PEI.
2.Use SwitchStack() between PEI and SMM in S3 resume path when both
  are in the same execution mode.
3.Transfer from PEI to OS waking vector by calling SwitchStack() when
  both are in the same execution mode.
4.Removed the debug assertion in S3Resume.c to support 64bit PEI.

Reviewed-by: Ray Ni 
Reviewed-by: Zhiguang Liu 
Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Star Zeng 
Cc: Ashraf Ali S 
Cc: Chinni B Duggapu 
Signed-off-by: Ted Kuo 

Modified: UefiCpuPkg/PiSmmCpuDxeSmm/CpuS3.c
Modified: UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
Modified: UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm
Modified: UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo Ersek
> Sent: Tuesday, May 23, 2023 1:46 PM
> To: Gerd Hoffmann ; Ni, Ray 
> Cc: Ard Biesheuvel ; edk2-devel-groups-io
> ; Yao, Jiewen ; Taylor Beebe
> ; Oliver Smith-Denny 
> Subject: Re: [edk2-devel] managing memory attributes in PEI
> 
> On 5/23/23 06:49, Gerd Hoffmann wrote:
> > On Mon, May 22, 2023 at 11:20:16PM +, Ni, Ray wrote:
> >> Gerd,
> >> The S3 path has been 64bit ready.
> >> Can you check if OVMF pei64 image can do s3?
> >>
> >> At least internally in some real platform we tested s3 flow with 64bit PEI.
> >
> > Tested on OVMF, passed too.
> >
> > Which are the commits implementing this?  I'd like the reference them in
> > the commit message for S3Verification() removal.
> 
> commit 6acf72901a2e / bug 4195, AFAIK; there could be other related
> commits since I last looked, of course
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105148): https://edk2.groups.io/g/devel/message/105148
Mute This Topic: https://groups.io/mt/99062463/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: 
https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

回复: [edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, May 23, 2023 #cal-reminder

[gaoliming via groups.io]

Few new issues are submitted. I will cancel this week meeting. 

 

Thanks

Liming

发件人: devel@edk2.groups.io  代表 Group Notification
发送时间: 2023年5月23日 9:30
收件人: devel@edk2.groups.io
主题: [edk2-devel] Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, May 23, 
2023 #cal-reminder

 

Reminder: TianoCore Bug Triage - APAC / NAMO 

When:
Tuesday, May 23, 2023
6:30pm to 7:30pm
(UTC-07:00) America/Los Angeles 

Where:
https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d
 

Organizer: Liming Gao gaolim...@byosoft.com.cn 

  

View Event  

Description:

TianoCore Bug Triage - APAC / NAMO

Hosted by Liming Gao

 


 

Microsoft Teams meeting 

Join on your computer or mobile app 

 

 Click here to join the meeting 

Join with a video conferencing device 

te...@conf.intel.com   

Video Conference ID: 116 062 094 0 

 

 Alternate VTC dialing instructions 

Or call in (audio only) 

  +1 916-245-6934,,77463821#   United States, 
Sacramento 

Phone Conference ID: 774 638 21# 

 

 Find a local number |   Reset 
PIN 

  Learn More |  

 Meeting options 





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105149): https://edk2.groups.io/g/devel/message/105149
Mute This Topic: https://groups.io/mt/99081918/21656
Mute #cal-reminder:https://edk2.groups.io/g/devel/mutehashtag/cal-reminder
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] Cancelled Event: TianoCore Bug Triage - APAC / NAMO - Tuesday, May 23, 2023 #cal-cancelled

[Group Notification]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Groups.io Inc//Groups.io Calendar//EN
METHOD:CANCELLED
REFRESH-INTERVAL;VALUE=DURATION:PT1H
X-PUBLISHED-TTL:PT1H
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:America/Los_Angeles
LAST-MODIFIED:20230407T050750Z
TZURL:https://www.tzurl.org/zoneinfo-outlook/America/Los_Angeles
X-LIC-LOCATION:America/Los_Angeles
BEGIN:DAYLIGHT
TZNAME:PDT
TZOFFSETFROM:-0800
TZOFFSETTO:-0700
DTSTART:19700308T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:PST
TZOFFSETFROM:-0700
TZOFFSETTO:-0800
DTSTART:19701101T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
X-GIOIDS:Event:1890530 
UID:mlda.1580078539586725120.r...@groups.io
DTSTAMP:20230523T061515Z
ORGANIZER;CN=Liming Gao:mailto:gaolim...@byosoft.com.cn
DTSTART:20230524T013000Z
DTEND:20230524T023000Z
SUMMARY:TianoCore Bug Triage - APAC / NAMO
DESCRIPTION:TianoCore Bug Triage - APAC / NAMO\n\nHosted by Liming Gao\n\
 n
 \n\nMicrosoft Teams meeting\n\n*Join on your computer or mobile a
 pp*\n\nClick here to join the meeting ( https://teams.microsoft.com/l/mee
 tup-join/19%3ameeting_OTk1YzJhN2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40
 thread.v2/0?context=%7b%22Tid%22%3a%2246c98d88-e344-4ed4-8496-4ed7712e255
 d%22%2c%22Oid%22%3a%226e4ce4c4-1242-431b-9a51-92cd01a5df3c%22%7d )\n\n*Jo
 in with a video conferencing device*\n\nte...@conf.intel.com\n\nVideo Con
 ference ID: 116 062 094 0\n\nAlternate VTC dialing instructions ( https:/
 /conf.intel.com/teams/?conf=1160620940&ivr=teams&d=conf.intel.com&test=te
 st_call )\n\n*Or call in (audio only)*\n\n+1 916-245-6934\,\,77463821# ( 
 tel:+19162456934\,\,77463821# ) United States\, Sacramento\n\nPhone Confe
 rence ID: 774 638 21#\n\nFind a local number ( https://dialin.teams.micro
 soft.com/d195d438-2daa-420e-b9ea-da26f9d1d6d5?id=77463821 ) | Reset PIN (
  https://mysettings.lync.com/pstnconferencing )\n\nLearn More ( https://a
 ka.ms/JoinTeamsMeeting ) | Meeting options ( https://teams.microsoft.com/
 meetingOptions/?organizerId=b286b53a-1218-4db3-bfc9-3d4c5aa7669e&tenantId
 =46c98d88-e344-4ed4-8496-4ed7712e255d&threadId=19_meeting_OTUyZTg2NjgtNDh
 lNS00ODVlLTllYTUtYzg1OTNjNjdiZjFh@thread.v2&messageId=0&language=en-US )
LOCATION:https://teams.microsoft.com/l/meetup-join/19%3ameeting_OTk1YzJhN
 2UtOGQwNi00NjY4LWEwMTktY2JiODRlYTY1NmY0%40thread.v2/0?context=%7b%22Tid%2
 2%3a%2246c98d88-e344-4ed4-8496-4ed7712e255d%22%2c%22Oid%22%3a%226e4ce4c4-
 1242-431b-9a51-92cd01a5df3c%22%7d
RECURRENCE-ID:20230524T013000Z
SEQUENCE:2
STATUS:CANCELLED
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics

Re: [edk2-devel] [PATCH v13 0/8] Adds AmdSmmCpuFeaturesLib and MmSaveStateLib

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Hi @Ray Ni,
We are almost there... We need your help to review this patch set as we need 
this library to be part of 202305 stable release.

Thanks
Abner



> -Original Message-
> From: Abdul Lateef Attar 
> Sent: Friday, May 12, 2023 8:32 PM
> To: devel@edk2.groups.io
> Cc: Attar, AbdulLateef (Abdul Lateef) ; Grimes,
> Paul ; Chang, Abner ; Eric
> Dong ; Ray Ni ; Rahul Kumar
> ; Gerd Hoffmann ; Michael D
> Kinney ; Liming Gao
> ; Zhiguang Liu ; Ard
> Biesheuvel ; Jiewen Yao
> ; Jordan Justen 
> Subject: [PATCH v13 0/8] Adds AmdSmmCpuFeaturesLib and
> MmSaveStateLib
>
> Backward-compatibility changes:
>   This patch series removes the SmmCpuFeaturesReadSaveStateRegister
>   and SmmCpuFeaturesWriteSaveStateRegister interface/function.
>   SmmReadSaveState() and SmmWriteSaveState() now directly invokes
> MmSaveStateLib
>   routines to save/restore registers.
>
> PR: https://github.com/tianocore/edk2/pull/4392
>
> V13: Delta changes
>   Address review comments from Ray Ni
>   Changed the BASE _NAME of AmdSmmCpuFeaturesLib.
>   Removed EFIAPI from local function.
>   Removed CpuIndex parameter from MmSaveStateGetRegisterLma
>   Modifed MmSaveStateGetRegisterIndex () to accept RegOffset
> as second parameter.
>   Removed FILE_GUID library instance for intel implemention from
> UefiCpuPkg.dsc.
>
> V12:
>   Addressed review comments from Michael.
>   Added LibraryClasses to .inf file.
>   removed duplicate MACRO definations.
>   Moved related MACRO defination to respective file.
> V11: Delta changes
>   Drop the OVMF implementation of MmSaveStateLib
> V10: Delta changes:
>   Addressed review comments from Abner.
> V9: Delta changes:
>   Addressed review comments.
>   Rename to MmSaveStateLib.
>   Also rename SMM_ defines to MM_.
>   Implemented OVMF MmSaveStateLib.
>   Removes SmmCpuFeaturesReadSaveStateRegister and
> SmmCpuFeaturesWriteSaveStateRegister
>   function interface.
> V8 delta changes:
>Addressed review comments from Abner,
>Fix the whitespace error.
>Seperate the Ovmf changes to another patch
> V7 delta changes:
>Adds SmmSmramSaveStateLib for Intel processor.
>Integrate SmmSmramSaveStateLib library.
> V6 delta changes:
>Addressed review comments for Ray NI.
>removed unnecessary EFIAPI.
> V5 delta changes:
>rebase to master branch.
>updated Reviewed-by
> V4 delta changes:
>   rebase to master branch.
>   added reviewed-by.
> V3 delta changes:
>   Addressed review comments from Abner chang.
>   Re-arranged patch order.
>
> Cc: Paul Grimes 
> Cc: Abner Chang 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Cc: Gerd Hoffmann 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Abdul Lateef Attar 
>
> Abdul Lateef Attar (8):
>   MdePkg: Adds AMD SMRAM save state map
>   UefiCpuPkg: Adds MmSaveStateLib library class
>   UefiCpuPkg: Implements MmSaveStateLib library instance
>   UefiCpuPkg/SmmCpuFeaturesLib: Restructure arch-dependent code
>   UefiCpuPkg: Implements SmmCpuFeaturesLib for AMD Family
>   UefiCpuPkg: Implements MmSaveStateLib for Intel
>   UefiCpuPkg: Removes SmmCpuFeaturesReadSaveStateRegister
>   OvmfPkg: Uses MmSaveStateLib library
>
>  UefiCpuPkg/UefiCpuPkg.dec |   4 +
>  OvmfPkg/OvmfPkgIa32.dsc   |   1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc|   3 +
>  OvmfPkg/OvmfPkgX64.dsc|   1 +
>  UefiCpuPkg/UefiCpuPkg.dsc |  13 +
>  .../MmSaveStateLib/AmdMmSaveStateLib.inf  |  34 +
>  .../MmSaveStateLib/IntelMmSaveStateLib.inf|  34 +
>  .../AmdSmmCpuFeaturesLib.inf  |  38 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf  |   2 +
>  .../Include/Register/Amd/SmramSaveStateMap.h  | 194 +
>  UefiCpuPkg/Include/Library/MmSaveStateLib.h   |  70 ++
>  .../Include/Library/SmmCpuFeaturesLib.h   |  52 --
>  .../Library/MmSaveStateLib/MmSaveState.h  |  94 +++
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h|  56 +-
>  .../SmmCpuFeaturesLib/SmmCpuFeaturesLib.c | 767 --
>  .../Library/MmSaveStateLib/AmdMmSaveState.c   | 309 +++
>  .../Library/MmSaveStateLib/IntelMmSaveState.c | 410 ++
>  .../MmSaveStateLib/MmSaveStateCommon.c| 132 +++
>  .../SmmCpuFeaturesLib/AmdSmmCpuFeaturesLib.c  | 387 +
>  .../IntelSmmCpuFeaturesLib.c  |  70 ++
>  .../SmmCpuFeaturesLibCommon.c | 128 ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c|  11 +-
>  UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c| 500 +---
>  MdePkg/MdePkg.ci.yaml |   4 +-
>  24 files changed, 1806 insertions(+), 1508 deletions(-)
>  create mode 100644
> UefiCpuPkg/Library/MmSaveStateLib/AmdMmSaveStateLib.inf
>  create mode 100644
> UefiCpuPkg/Library/MmSaveStateLib/IntelMmSaveStateLib.inf
>  create mode 100644
> UefiCpuPkg/Library/SmmCpuFeaturesLib/AmdSmmCpuFea

Re: [edk2-devel] [PATCH v13 0/8] Adds AmdSmmCpuFeaturesLib and MmSaveStateLib

[Ni, Ray]

Abner,
Sure. I will review the new patch set.

But I am afraid this patch set cannot be included in 202305 stable release 
because the edk2 repo
has been locked for quite a while for 202305 release and is about to unlocked.

Thanks,
Ray

> -Original Message-
> From: Chang, Abner 
> Sent: Tuesday, May 23, 2023 2:28 PM
> To: Attar, AbdulLateef (Abdul Lateef) ;
> devel@edk2.groups.io; Ni, Ray 
> Cc: Attar, AbdulLateef (Abdul Lateef) ; Grimes,
> Paul ; Dong, Eric ; Kumar, Rahul
> R ; Gerd Hoffmann ; Kinney,
> Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Ard
> Biesheuvel ; Yao, Jiewen ;
> Justen, Jordan L 
> Subject: RE: [PATCH v13 0/8] Adds AmdSmmCpuFeaturesLib and MmSaveStateLib
> 
> [AMD Official Use Only - General]
> 
> Hi @Ray Ni,
> We are almost there... We need your help to review this patch set as we need
> this library to be part of 202305 stable release.
> 
> Thanks
> Abner
> 
> 
> 
> > -Original Message-
> > From: Abdul Lateef Attar 
> > Sent: Friday, May 12, 2023 8:32 PM
> > To: devel@edk2.groups.io
> > Cc: Attar, AbdulLateef (Abdul Lateef) ; Grimes,
> > Paul ; Chang, Abner ; Eric
> > Dong ; Ray Ni ; Rahul Kumar
> > ; Gerd Hoffmann ; Michael D
> > Kinney ; Liming Gao
> > ; Zhiguang Liu ; Ard
> > Biesheuvel ; Jiewen Yao
> > ; Jordan Justen 
> > Subject: [PATCH v13 0/8] Adds AmdSmmCpuFeaturesLib and
> > MmSaveStateLib
> >
> > Backward-compatibility changes:
> >   This patch series removes the SmmCpuFeaturesReadSaveStateRegister
> >   and SmmCpuFeaturesWriteSaveStateRegister interface/function.
> >   SmmReadSaveState() and SmmWriteSaveState() now directly invokes
> > MmSaveStateLib
> >   routines to save/restore registers.
> >
> > PR: https://github.com/tianocore/edk2/pull/4392
> >
> > V13: Delta changes
> >   Address review comments from Ray Ni
> >   Changed the BASE _NAME of AmdSmmCpuFeaturesLib.
> >   Removed EFIAPI from local function.
> >   Removed CpuIndex parameter from MmSaveStateGetRegisterLma
> >   Modifed MmSaveStateGetRegisterIndex () to accept RegOffset
> > as second parameter.
> >   Removed FILE_GUID library instance for intel implemention from
> > UefiCpuPkg.dsc.
> >
> > V12:
> >   Addressed review comments from Michael.
> >   Added LibraryClasses to .inf file.
> >   removed duplicate MACRO definations.
> >   Moved related MACRO defination to respective file.
> > V11: Delta changes
> >   Drop the OVMF implementation of MmSaveStateLib
> > V10: Delta changes:
> >   Addressed review comments from Abner.
> > V9: Delta changes:
> >   Addressed review comments.
> >   Rename to MmSaveStateLib.
> >   Also rename SMM_ defines to MM_.
> >   Implemented OVMF MmSaveStateLib.
> >   Removes SmmCpuFeaturesReadSaveStateRegister and
> > SmmCpuFeaturesWriteSaveStateRegister
> >   function interface.
> > V8 delta changes:
> >Addressed review comments from Abner,
> >Fix the whitespace error.
> >Seperate the Ovmf changes to another patch
> > V7 delta changes:
> >Adds SmmSmramSaveStateLib for Intel processor.
> >Integrate SmmSmramSaveStateLib library.
> > V6 delta changes:
> >Addressed review comments for Ray NI.
> >removed unnecessary EFIAPI.
> > V5 delta changes:
> >rebase to master branch.
> >updated Reviewed-by
> > V4 delta changes:
> >   rebase to master branch.
> >   added reviewed-by.
> > V3 delta changes:
> >   Addressed review comments from Abner chang.
> >   Re-arranged patch order.
> >
> > Cc: Paul Grimes 
> > Cc: Abner Chang 
> > Cc: Eric Dong 
> > Cc: Ray Ni 
> > Cc: Rahul Kumar 
> > Cc: Gerd Hoffmann 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Ard Biesheuvel 
> > Cc: Jiewen Yao 
> > Cc: Jordan Justen 
> > Cc: Abdul Lateef Attar 
> >
> > Abdul Lateef Attar (8):
> >   MdePkg: Adds AMD SMRAM save state map
> >   UefiCpuPkg: Adds MmSaveStateLib library class
> >   UefiCpuPkg: Implements MmSaveStateLib library instance
> >   UefiCpuPkg/SmmCpuFeaturesLib: Restructure arch-dependent code
> >   UefiCpuPkg: Implements SmmCpuFeaturesLib for AMD Family
> >   UefiCpuPkg: Implements MmSaveStateLib for Intel
> >   UefiCpuPkg: Removes SmmCpuFeaturesReadSaveStateRegister
> >   OvmfPkg: Uses MmSaveStateLib library
> >
> >  UefiCpuPkg/UefiCpuPkg.dec |   4 +
> >  OvmfPkg/OvmfPkgIa32.dsc   |   1 +
> >  OvmfPkg/OvmfPkgIa32X64.dsc|   3 +
> >  OvmfPkg/OvmfPkgX64.dsc|   1 +
> >  UefiCpuPkg/UefiCpuPkg.dsc |  13 +
> >  .../MmSaveStateLib/AmdMmSaveStateLib.inf  |  34 +
> >  .../MmSaveStateLib/IntelMmSaveStateLib.inf|  34 +
> >  .../AmdSmmCpuFeaturesLib.inf  |  38 +
> >  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf  |   2 +
> >  .../Include/Register/Amd/SmramSaveStateMap.h  | 194 +
> >  UefiCpuPkg/Include/Library/MmSaveStateLib.h   |  70 ++
> >  .../Include/Library/SmmCpuFeaturesLib.h   |  52 --
> >  .../Library/MmSaveStateLib/MmSaveState.h  |  94 +++
> >  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h 

Re: [edk2-devel] [PATCH v13 0/8] Adds AmdSmmCpuFeaturesLib and MmSaveStateLib

[Chang, Abner via groups.io]

[AMD Official Use Only - General]

Let's talk to Liming to see if we have chance to make this included in 202305 
as the review process of this patch set looks to me close to finish.

Thanks
Abner

> -Original Message-
> From: Ni, Ray 
> Sent: Tuesday, May 23, 2023 2:30 PM
> To: Chang, Abner ; Attar, AbdulLateef (Abdul
> Lateef) ; devel@edk2.groups.io
> Cc: Attar, AbdulLateef (Abdul Lateef) ; Grimes,
> Paul ; Dong, Eric ; Kumar,
> Rahul R ; Gerd Hoffmann ;
> Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Ard
> Biesheuvel ; Yao, Jiewen
> ; Justen, Jordan L 
> Subject: RE: [PATCH v13 0/8] Adds AmdSmmCpuFeaturesLib and
> MmSaveStateLib
>
> [AMD Official Use Only - General]
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> Abner,
> Sure. I will review the new patch set.
>
> But I am afraid this patch set cannot be included in 202305 stable release
> because the edk2 repo
> has been locked for quite a while for 202305 release and is about to unlocked.
>
> Thanks,
> Ray
>
> > -Original Message-
> > From: Chang, Abner 
> > Sent: Tuesday, May 23, 2023 2:28 PM
> > To: Attar, AbdulLateef (Abdul Lateef) ;
> > devel@edk2.groups.io; Ni, Ray 
> > Cc: Attar, AbdulLateef (Abdul Lateef) ;
> Grimes,
> > Paul ; Dong, Eric ; Kumar,
> Rahul
> > R ; Gerd Hoffmann ;
> Kinney,
> > Michael D ; Gao, Liming
> > ; Liu, Zhiguang ; Ard
> > Biesheuvel ; Yao, Jiewen
> ;
> > Justen, Jordan L 
> > Subject: RE: [PATCH v13 0/8] Adds AmdSmmCpuFeaturesLib and
> MmSaveStateLib
> >
> > [AMD Official Use Only - General]
> >
> > Hi @Ray Ni,
> > We are almost there... We need your help to review this patch set as we
> need
> > this library to be part of 202305 stable release.
> >
> > Thanks
> > Abner
> >
> >
> >
> > > -Original Message-
> > > From: Abdul Lateef Attar 
> > > Sent: Friday, May 12, 2023 8:32 PM
> > > To: devel@edk2.groups.io
> > > Cc: Attar, AbdulLateef (Abdul Lateef) ;
> Grimes,
> > > Paul ; Chang, Abner ;
> Eric
> > > Dong ; Ray Ni ; Rahul Kumar
> > > ; Gerd Hoffmann ;
> Michael D
> > > Kinney ; Liming Gao
> > > ; Zhiguang Liu ; Ard
> > > Biesheuvel ; Jiewen Yao
> > > ; Jordan Justen 
> > > Subject: [PATCH v13 0/8] Adds AmdSmmCpuFeaturesLib and
> > > MmSaveStateLib
> > >
> > > Backward-compatibility changes:
> > >   This patch series removes the SmmCpuFeaturesReadSaveStateRegister
> > >   and SmmCpuFeaturesWriteSaveStateRegister interface/function.
> > >   SmmReadSaveState() and SmmWriteSaveState() now directly invokes
> > > MmSaveStateLib
> > >   routines to save/restore registers.
> > >
> > > PR: https://github.com/tianocore/edk2/pull/4392
> > >
> > > V13: Delta changes
> > >   Address review comments from Ray Ni
> > >   Changed the BASE _NAME of AmdSmmCpuFeaturesLib.
> > >   Removed EFIAPI from local function.
> > >   Removed CpuIndex parameter from MmSaveStateGetRegisterLma
> > >   Modifed MmSaveStateGetRegisterIndex () to accept RegOffset
> > > as second parameter.
> > >   Removed FILE_GUID library instance for intel implemention from
> > > UefiCpuPkg.dsc.
> > >
> > > V12:
> > >   Addressed review comments from Michael.
> > >   Added LibraryClasses to .inf file.
> > >   removed duplicate MACRO definations.
> > >   Moved related MACRO defination to respective file.
> > > V11: Delta changes
> > >   Drop the OVMF implementation of MmSaveStateLib
> > > V10: Delta changes:
> > >   Addressed review comments from Abner.
> > > V9: Delta changes:
> > >   Addressed review comments.
> > >   Rename to MmSaveStateLib.
> > >   Also rename SMM_ defines to MM_.
> > >   Implemented OVMF MmSaveStateLib.
> > >   Removes SmmCpuFeaturesReadSaveStateRegister and
> > > SmmCpuFeaturesWriteSaveStateRegister
> > >   function interface.
> > > V8 delta changes:
> > >Addressed review comments from Abner,
> > >Fix the whitespace error.
> > >Seperate the Ovmf changes to another patch
> > > V7 delta changes:
> > >Adds SmmSmramSaveStateLib for Intel processor.
> > >Integrate SmmSmramSaveStateLib library.
> > > V6 delta changes:
> > >Addressed review comments for Ray NI.
> > >removed unnecessary EFIAPI.
> > > V5 delta changes:
> > >rebase to master branch.
> > >updated Reviewed-by
> > > V4 delta changes:
> > >   rebase to master branch.
> > >   added reviewed-by.
> > > V3 delta changes:
> > >   Addressed review comments from Abner chang.
> > >   Re-arranged patch order.
> > >
> > > Cc: Paul Grimes 
> > > Cc: Abner Chang 
> > > Cc: Eric Dong 
> > > Cc: Ray Ni 
> > > Cc: Rahul Kumar 
> > > Cc: Gerd Hoffmann 
> > > Cc: Michael D Kinney 
> > > Cc: Liming Gao 
> > > Cc: Zhiguang Liu 
> > > Cc: Ard Biesheuvel 
> > > Cc: Jiewen Yao 
> > > Cc: Jordan Justen 
> > > Cc: Abdul Lateef Attar 
> > >
> > > Abdul Lateef Attar (8):
> > >   MdePkg: Adds AMD SMRAM save state map
> > >   UefiCpuPkg: Adds MmSaveStateLib library class
> > >   UefiCpuPkg: Implements MmSaveStateLib library instance
> > >   UefiCpuPkg/SmmCp

Re: [edk2-devel] [PATCH 3/3] CloudHv:arm: add kernel load driver into dsc/fdf

[Jianyong Wu]

Hello Sami,

Any comments about the memory layout below?

Thanks
Jianyong

From: Jianyong Wu
Sent: 2023年4月24日 10:37
To: devel@edk2.groups.io; Jianyong Wu ; Sami Mujawar 

Cc: ardb+tianoc...@kernel.org; Justin He ; nd 
Subject: RE: [edk2-devel] [PATCH 3/3] CloudHv:arm: add kernel load driver into 
dsc/fdf

Hi Sami,

Following the last discussion, I check the Cpu stack in edk2 and draw a draft 
for the memory layout of Cpu stack, Initrd and Kernel image: see it below:

|-| <-- top of memory   ---|
| ||
|primary cpu stack (16KB) |\
| |/ reserve 2MB is enough
|-||
|  secondary cpus stack   ||
|  (4KB * (cputcount-1))  ||
|-| <-- top of cpu stack --|
| |
| initrd image|
|(64MB)   |
| |
|-|
| |
| kernel image|
|(64MB)   |
| |
|-|
| |
| |
| |
|  normal memory region   |
| |
| |
| |
|-| <-- memory base address

That’s say, the top 2MB of memory region reserved for Cpu stack. It’s enough as 
it can accommodate for more than 500 Cpus. There are two 64MB regions reserved 
below Cpu stack, one for Initrd and another for Kernel image.
We can guarantee there is no confliction between each other in cloud hypervisor 
and double check it in edk2 by checking if there is 2MB region reserved for Cpu 
stack.

WDYT?

Thanks
Jianyong
From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> On Behalf Of Jianyong Wu 
via groups.io
Sent: 2023年1月11日 17:28
To: Sami Mujawar mailto:sami.muja...@arm.com>>; 
devel@edk2.groups.io
Cc: ardb+tianoc...@kernel.org; Justin He 
mailto:justin...@arm.com>>; nd 
mailto:n...@arm.com>>
Subject: Re: [edk2-devel] [PATCH 3/3] CloudHv:arm: add kernel load driver into 
dsc/fdf

Hi Sami,

Thanks for quick response.

The other comment (probably for patch 2/3 in this series) was with regards to 
the memory reservation for the Initrd and Kernel arguments. I think these 
regions should be reserved (in addition to the kernel region) to avoid any 
accidental overwriting. I believe if you start reducing the System Memory size 
at some point you may find that the Initrd and Kernel arguments are 
overwritten. Can you check this, please?

For the current implementation, initrd has been considered and placed on the 
top of memory in Cloud Hypervisor. And for kernel image, in the current design, 
is placed under initrd image. As to kernel parameters, it is just a string in 
“chosen node” and will not occupy memory. So, I think, in general, it won’t 
happen of accidental overwriting. But I need to set to memory region for initrd 
image to read-only like kernel does to avoid the memory being allocated.

Can you also check if there is a possibility that these regions could overlap 
the CPU stack, etc. and if so, how do we make sure this never happens?

Generally, kernel stack locates at the lowest part of memory. I think it’s safe 
to place Kernel and Initrd image on the top of memory, unless the memory size 
is too small.

WDYT?

Thanks
Jianyong

From: Sami Mujawar mailto:sami.muja...@arm.com>>
Sent: Wednesday, January 11, 2023 4:35 PM
To: Jianyong Wu mailto:jianyong...@arm.com>>; 
devel@edk2.groups.io
Cc: ardb+tianoc...@kernel.org; Justin He 
mailto:justin...@arm.com>>; nd 
mailto:n...@arm.com>>
Subject: Re: [edk2-devel] [PATCH 3/3] CloudHv:arm: add kernel load driver into 
dsc/fdf

Hi Jianyong,

Thank you for your kind wishes and happy new year to you.

I think linking with a NULL lib implementation of QemuBootOrderLib would be 
good.

The other comment (probably for patch 2/3 in this series) was with regards to 
the memory reservation for the Initrd and Kernel arguments. I think these 
regions should be reserved (in addition to the kernel region) to avoid any 
accidental overwriting. I believe if you start reducing the System Memory size 
at some point you may find that the Initrd and Kernel arguments are 
overwritten. Can you check this, please?
Can you also check if there is a possibility that these regions could overlap 
the CPU stack, etc. and if so, how do we make sure this never happens?

Regards,

Sami Mujawar

From: Jianyong Wu mailto:jianyong...@arm.com>>
Date: Wednesday, 11 January 2023 at 08:12
To: "devel@edk2.groups.io" 
mailto:devel@edk2.groups.io>>, Jianyong Wu 
mailto:j

Re: [edk2-devel] [PATCH edk2-stable202305] ArmPkg/ArmMmuLib: Add missing ISB after page table update

[Ard Biesheuvel]

On Tue, 23 May 2023 at 02:44, Kinney, Michael D
 wrote:
>
> I have set push label.  It is merged now.
>
> During hard freeze, the release owner and stewards are the only once that can 
> set the label.
>

Yeah that seems fair. Thanks.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105155): https://edk2.groups.io/g/devel/message/105155
Mute This Topic: https://groups.io/mt/99027974/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-