date:20230331

Re: [edk2-devel] [PATCH v3 1/3] Platform/AMD: Adds MinBoardPkg to support MinPlatformPkg

2023-03-31 Thread Chang, Abner via groups.io

[AMD Official Use Only - General]

Hi Sean,
Could you please elaborate more about the issue of package name collision? CI 
tool may have problem if same package name under two different folders (such as 
Intel/MinBoardPkg and AMD/MinBoardPkg)?
MinBoardPkg is under AMD folder which seems to me that package is for AMD 
specifically.
Thanks
Abner


> -Original Message-
> From: Sean Brogan 
> Sent: Saturday, April 1, 2023 4:20 AM
> To: devel@edk2.groups.io; Attar, AbdulLateef (Abdul Lateef)
> 
> Cc: Ard Biesheuvel ; Leif Lindholm
> ; Chang, Abner ;
> Michael D Kinney 
> Subject: Re: [edk2-devel] [PATCH v3 1/3] Platform/AMD: Adds MinBoardPkg
> to support MinPlatformPkg
> 
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
> 
> 
> Regardless of directory path I would suggest that all "Packages" have a
> unique and descriptive name.  MinBoardPkg doesn't meet that
> suggestion.   If/when the edk2 CI tools run I would expect problems/odd
> behavior if two packages collide in naming.
> 
> Thanks
> 
> Sean
> 
> 
> 
> On 3/22/2023 11:13 PM, Abdul Lateef Attar via groups.io wrote:
> > Adds initial DEC and DSC file for MinBoardPkg.
> > This package provides supporting modules for AMD boards to leverage
> > MinPlatformPkg framework.
> >
> > Signed-off-by: Abdul Lateef Attar 
> > Cc: Ard Biesheuvel 
> > Cc: Leif Lindholm 
> > Cc: Abner Chang 
> > Cc: Michael D Kinney 
> > ---
> >   Platform/AMD/MinBoardPkg/MinBoardPkg.dec | 19
> +++
> >   Platform/AMD/MinBoardPkg/MinBoardPkg.dsc | 21
> +
> >   2 files changed, 40 insertions(+)
> >   create mode 100644 Platform/AMD/MinBoardPkg/MinBoardPkg.dec
> >   create mode 100644 Platform/AMD/MinBoardPkg/MinBoardPkg.dsc
> >
> > diff --git a/Platform/AMD/MinBoardPkg/MinBoardPkg.dec
> > b/Platform/AMD/MinBoardPkg/MinBoardPkg.dec
> > new file mode 100644
> > index ..23d737d196a2
> > --- /dev/null
> > +++ b/Platform/AMD/MinBoardPkg/MinBoardPkg.dec
> > @@ -0,0 +1,19 @@
> > +## @file MinBoardPkg.dec
> > +#  Declaration file for AMD's MinBoardPkg.
> > +#
> > +#  This package supports AMD processor family based board as per the
> > +MinPlatform #  Arch specification.
> > +#
> > +#  Copyright (c) 2023, Advanced Micro Devices, Inc. All rights reserved.
> > +#  SPDX-License-Identifier: BSD-2-Clause-Patent # #  @par
> > +Specification Reference:
> > +#   -https://tianocore-docs.github.io/edk2-
> MinimumPlatformSpecification/draft/ 0.7
> > +##
> > +
> > +[Defines]
> > +  DEC_SPECIFICATION  = 1.27
> > +  PACKAGE_NAME   = MinBoardPkg
> > +  PACKAGE_GUID   = 44F9D761-9ECB-43DD-A5AC-177E5048701B
> > +  PACKAGE_VERSION= 0.1
> > +
> > diff --git a/Platform/AMD/MinBoardPkg/MinBoardPkg.dsc
> > b/Platform/AMD/MinBoardPkg/MinBoardPkg.dsc
> > new file mode 100644
> > index ..8c120c0649e7
> > --- /dev/null
> > +++ b/Platform/AMD/MinBoardPkg/MinBoardPkg.dsc
> > @@ -0,0 +1,21 @@
> > +## @file
> > +#  MinBoardPkg.dsc
> > +#
> > +#  Description file for AMD MinBoardPkg # #  Copyright (c) 2023,
> > +Advanced Micro Devices, Inc. All rights reserved.
> > +#  SPDX-License-Identifier: BSD-2-Clause-Patent ##
> > +
> > +[Defines]
> > +  DSC_SPECIFICATION   = 1.30
> > +  PLATFORM_GUID   = 88F8A9AE-2FA0-4D58-A6F9-05F635C05F4E
> > +  PLATFORM_NAME   = MinBoardPkg
> > +  PLATFORM_VERSION= 0.1
> > +  OUTPUT_DIRECTORY= Build/$(PLATFORM_NAME)
> > +  BUILD_TARGETS   = DEBUG | RELEASE | NOOPT
> > +  SUPPORTED_ARCHITECTURES = IA32 | X64
> > +
> > +[Packages]
> > +  MinBoardPkg/MinBoardPkg.dec
> > +


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

Re: [edk2-devel] [PATCH 0/2] Support FDT library.

2023-03-31 Thread Andrei Warkentin

How does this relate to the existing EmbeddedPkg/Library/FdtLib code? Is there 
a specific plan to move away from this in existing components?

I did look in the BZ (https://bugzilla.tianocore.org/show_bug.cgi?id=4392) but 
this doesn't seem to acknowledge that there is existing Fdt support in 
EmbeddedPkg.

A

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Benny
> Lin
> Sent: Thursday, March 30, 2023 11:52 AM
> To: devel@edk2.groups.io
> Cc: Lin, Benny ; Kinney, Michael D
> ; Gao, Liming ;
> Liu, Zhiguang ; Sean Brogan
> ; Michael Kubacki
> 
> Subject: [edk2-devel] [PATCH 0/2] Support FDT library.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4392
> Add FDT support in EDK2 by submodule 3rd party libfdt
> (https://github.com/devicetree-org/pylibfdt/tree/main/libfdt)
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Sean Brogan 
> Cc: Michael Kubacki 
> Signed-off-by: Benny Lin 
> 
> Benny Lin (2):
>   MdePkg: Support FDT library.
>   .pytool: Support FDT library.
> 
>  .gitmodules   |   3 +
>  .pytool/CISettings.py |   2 +
>  MdePkg/Include/Library/FdtLib.h   | 300 ++
>  MdePkg/Library/BaseFdtLib/BaseFdtLib.inf  |  62 +
> MdePkg/Library/BaseFdtLib/BaseFdtLib.uni  |  14 +
>  MdePkg/Library/BaseFdtLib/FdtLib.c| 284 
>  MdePkg/Library/BaseFdtLib/LibFdtSupport.h | 102 
> MdePkg/Library/BaseFdtLib/LibFdtWrapper.c | 138 ++
>  MdePkg/Library/BaseFdtLib/libfdt  |   1 +
>  MdePkg/Library/BaseFdtLib/limits.h|  10 +
>  MdePkg/Library/BaseFdtLib/stdbool.h   |  10 +
>  MdePkg/Library/BaseFdtLib/stddef.h|  10 +
>  MdePkg/Library/BaseFdtLib/stdint.h|  10 +
>  MdePkg/Library/BaseFdtLib/stdlib.h|  10 +
>  MdePkg/Library/BaseFdtLib/string.h|  10 +
>  MdePkg/MdePkg.ci.yaml |  17 +-
>  MdePkg/MdePkg.dec |   4 +
>  MdePkg/MdePkg.dsc |   2 +
>  ReadMe.rst|   1 +
>  19 files changed, 988 insertions(+), 2 deletions(-)  create mode 100644
> MdePkg/Include/Library/FdtLib.h  create mode 100644
> MdePkg/Library/BaseFdtLib/BaseFdtLib.inf
>  create mode 100644 MdePkg/Library/BaseFdtLib/BaseFdtLib.uni
>  create mode 100644 MdePkg/Library/BaseFdtLib/FdtLib.c
>  create mode 100644 MdePkg/Library/BaseFdtLib/LibFdtSupport.h
>  create mode 100644 MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
>  create mode 16 MdePkg/Library/BaseFdtLib/libfdt  create mode 100644
> MdePkg/Library/BaseFdtLib/limits.h
>  create mode 100644 MdePkg/Library/BaseFdtLib/stdbool.h
>  create mode 100644 MdePkg/Library/BaseFdtLib/stddef.h
>  create mode 100644 MdePkg/Library/BaseFdtLib/stdint.h
>  create mode 100644 MdePkg/Library/BaseFdtLib/stdlib.h
>  create mode 100644 MdePkg/Library/BaseFdtLib/string.h
> 
> --
> 2.39.1.windows.1
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v1 1/1] .github/dependabot.yml: Disable automatic rebasing

2023-03-31 Thread Michael D Kinney

Reviewed-by: Michael D Kinney 


> -Original Message-
> From: mikub...@linux.microsoft.com 
> Sent: Friday, March 31, 2023 4:49 PM
> To: devel@edk2.groups.io
> Cc: Sean Brogan ; Kinney, Michael D 
> 
> Subject: [PATCH v1 1/1] .github/dependabot.yml: Disable automatic rebasing
> 
> From: Michael Kubacki 
> 
> Sets the rebase-strategy to "disabled" to prevent automatic
> rebasing.
> 
> Rebasing can be done manually in the dependabot PR either through
> the GitHub UI or the dependabot command.
> 
> Cc: Sean Brogan 
> Cc: Michael D Kinney 
> Signed-off-by: Michael Kubacki 
> ---
>  .github/dependabot.yml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/.github/dependabot.yml b/.github/dependabot.yml
> index b4e0b93b16ca..479440fe6397 100644
> --- a/.github/dependabot.yml
> +++ b/.github/dependabot.yml
> @@ -20,6 +20,7 @@ updates:
>- "makubacki"
>- "mdkinney"
>- "spbrogan"
> +rebase-strategy: "disabled"
> 
>- package-ecosystem: "github-actions"
>  directory: "/"
> @@ -32,3 +33,4 @@ updates:
>- "makubacki"
>- "mdkinney"
>- "spbrogan"
> +rebase-strategy: "disabled"
> --
> 2.40.0.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102343): https://edk2.groups.io/g/devel/message/102343
Mute This Topic: https://groups.io/mt/97985364/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][PATCH v1 1/2] UefiPayloadPkg: Always build MemoryTypeInformation HOB for DXE GCD

2023-03-31 Thread Benjamin Doron

MemoryType information assists GCD with defragmenting the memory map.
When the DXE core starts, GCD adds memory descriptors for the resource
descriptors HOBs. This allocates heap space which can be reused later
as the bins by memory type. It seems memory allocation prefers low
ranges.

It seems "below 4G" is an artifact of this heap reuse. However, the
memory type information determines the DXE core's
`MinimalMemorySizeNeeded`, determining which system memory descriptor
HOB may be used by DXE. Furthermore, it's important that the memory
type information be correct, for an S4 memory map.

Therefore, follow other bootloaders, such as [MinPlatform][1], and do
this unconditionally. As of [edk2-stable202011][2], it was.

[1]: 
https://github.com/tianocore/edk2-platforms/blob/b6f96743891be51541184bf61dd2970c008e2c43/Platform/Intel/MinPlatformPkg/PlatformInit/PlatformInitPei/PlatformInitPreMem.c#L164-L201
[2]: 
https://github.com/tianocore/edk2/blob/edk2-stable202011/UefiPayloadPkg/BlSupportPei/BlSupportPei.c#L462-L466

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: Benjamin Doron 
---
 .../UefiPayloadEntry/UefiPayloadEntry.c   | 36 +--
 .../UefiPayloadEntry/UefiPayloadEntry.inf |  2 --
 UefiPayloadPkg/UefiPayloadPkg.dec |  3 --
 UefiPayloadPkg/UefiPayloadPkg.dsc |  2 --
 4 files changed, 8 insertions(+), 35 deletions(-)

diff --git a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c 
b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
index 780348eadfa8..030a5baed914 100644
--- a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
+++ b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
@@ -19,30 +19,6 @@ EFI_MEMORY_TYPE_INFORMATION  mDefaultMemoryTypeInformation[] 
= {
   { EfiMaxMemoryType,   0  
 }
 };
 
-/**
-   Function to reserve memory below 4GB for EDKII Modules.
-
-   This causes the DXE to dispatch everything under 4GB and allows Operating
-   System's that require EFI_LOADED_IMAGE to be under 4GB to start.
-   e.g. Xen hypervisor used in Qubes.
-**/
-VOID
-ForceModulesBelow4G (
-  VOID
-  )
-{
-  DEBUG ((DEBUG_INFO, "Building hob to restrict memory resorces to below 
4G.\n"));
-
-  //
-  // Create Memory Type Information HOB
-  //
-  BuildGuidDataHob (
-,
-mDefaultMemoryTypeInformation,
-sizeof (mDefaultMemoryTypeInformation)
-);
-}
-
 /**
Callback function to build resource descriptor HOB
 
@@ -472,10 +448,14 @@ _ModuleEntryPoint (
   // Build other HOBs required by DXE
   BuildGenericHob ();
 
-  // Create a HOB to make resources for EDKII modules below 4G
-  if (!FixedPcdGetBool (PcdDispatchModuleAbove4GMemory)) {
-ForceModulesBelow4G ();
-  }
+  //
+  // Create Memory Type Information HOB
+  //
+  BuildGuidDataHob (
+,
+mDefaultMemoryTypeInformation,
+sizeof (mDefaultMemoryTypeInformation)
+);
 
   // Load the DXE Core
   Status = LoadDxeCore ();
diff --git a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf 
b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
index d47e8e76cf4c..e2af8a4b7c1b 100644
--- a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
+++ b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.inf
@@ -96,5 +96,3 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy ## 
SOMETIMES_CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy   ## 
SOMETIMES_CONSUMES
 
-  gUefiPayloadPkgTokenSpaceGuid.PcdDispatchModuleAbove4GMemory
-
diff --git a/UefiPayloadPkg/UefiPayloadPkg.dec 
b/UefiPayloadPkg/UefiPayloadPkg.dec
index 7d61d6eeae6c..2ed73513700d 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dec
+++ b/UefiPayloadPkg/UefiPayloadPkg.dec
@@ -82,9 +82,6 @@ 
gUefiPayloadPkgTokenSpaceGuid.PcdSystemMemoryUefiRegionSize|0x0400|UINT32|0x
 
 gUefiPayloadPkgTokenSpaceGuid.PcdPcdDriverFile|{ 0x57, 0x72, 0xcf, 0x80, 0xab, 
0x87, 0xf9, 0x47, 0xa3, 0xfe, 0xD5, 0x0B, 0x76, 0xd8, 0x95, 0x41 
}|VOID*|0x0018
 
-# Above 4G Memory
-gUefiPayloadPkgTokenSpaceGuid.PcdDispatchModuleAbove4GMemory|TRUE|BOOLEAN|0x0019
-
 # Boot Manager Key
 gUefiPayloadPkgTokenSpaceGuid.PcdBootManagerEscape|FALSE|BOOLEAN|0x0020
 
diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc 
b/UefiPayloadPkg/UefiPayloadPkg.dsc
index bca5d3f335bc..9847f189fff5 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -34,7 +34,6 @@
   DEFINE SECURITY_STUB_ENABLE = TRUE
   DEFINE SMM_SUPPORT  = FALSE
   DEFINE PLATFORM_BOOT_TIMEOUT= 3
-  DEFINE ABOVE_4G_MEMORY  = TRUE
   DEFINE BOOT_MANAGER_ESCAPE  = FALSE
   DEFINE ATA_ENABLE   = TRUE
   DEFINE SD_ENABLE= TRUE
@@ -442,7 +441,6 @@
 !endif
   gEfiMdeModulePkgTokenSpaceGuid.PcdSdMmcGenericTimeoutValue|$(SD_MMC_TIMEOUT)
 
-  
gUefiPayloadPkgTokenSpaceGuid.PcdDispatchModuleAbove4GMemory|$(ABOVE_4G_MEMORY)

[edk2-devel][PATCH v1 2/2] UefiPayloadPkg: Update default memory type information for S4

2023-03-31 Thread Benjamin Doron

Copied values from OVMF, these are sufficient for a debug build.

Now that those are improved, remove
PcdResetOnMemoryTypeInformationChange override. If the memory map must
change, reset system so that an S4 resume will succeed.

Requires testing a hibernate resume to OS.

Cc: Guo Dong 
Cc: Ray Ni 
Cc: Sean Rhodes 
Cc: James Lu 
Cc: Gua Guo 
Signed-off-by: Benjamin Doron 
---
 UefiPayloadPkg/UefiPayloadPkg.dec | 6 +++---
 UefiPayloadPkg/UefiPayloadPkg.dsc | 1 -
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/UefiPayloadPkg/UefiPayloadPkg.dec 
b/UefiPayloadPkg/UefiPayloadPkg.dec
index 2ed73513700d..a5004a2b616e 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dec
+++ b/UefiPayloadPkg/UefiPayloadPkg.dec
@@ -71,11 +71,11 @@ 
gUefiPayloadPkgTokenSpaceGuid.PcdBootloaderParameter|0|UINT64|0x1004
 gUefiPayloadPkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 
0x9E, 0x1c, 0x4f, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 
}|VOID*|0x1005
 
 ## Used to help reduce fragmentation in the EFI memory map
-gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x08|UINT32|0x1012
+gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0x12|UINT32|0x1012
 
gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0x04|UINT32|0x1013
 
gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0x04|UINT32|0x0014
-gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0xC0|UINT32|0x0015
-gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x80|UINT32|0x0016
+gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|0x100|UINT32|0x0015
+gUefiPayloadPkgTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|0x100|UINT32|0x0016
 
 # Size of the region used by UEFI in permanent memory
 
gUefiPayloadPkgTokenSpaceGuid.PcdSystemMemoryUefiRegionSize|0x0400|UINT32|0x0017
diff --git a/UefiPayloadPkg/UefiPayloadPkg.dsc 
b/UefiPayloadPkg/UefiPayloadPkg.dsc
index 9847f189fff5..ba6cc7e1a4d8 100644
--- a/UefiPayloadPkg/UefiPayloadPkg.dsc
+++ b/UefiPayloadPkg/UefiPayloadPkg.dsc
@@ -539,7 +539,6 @@
 !else
   gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|FALSE
 !endif
-  gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
   gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase|0
-- 
2.39.1



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

Re: [edk2-devel] [PATCH] UefiCpuPkg/Test: Disable random test cases

2023-03-31 Thread Michael Kubacki

Since we use those PRs for reference only. I think we can let the 
initial CI run, keep that for reference, and prevent future automated 
rebases in the dependabot PR.


Future CI will occur in the PR created by the patch that contains the 
update.


With that in mind, I sent a patch to disable automatic rebasing in 
dependabot PRs.


https://edk2.groups.io/g/devel/message/102338

Thanks,
Michael

On 3/31/2023 7:14 PM, Kinney, Michael D wrote:

Michael,

I see older PRs from dependabot still running jobs.

Is there a way to configure how often those checks are made?

Mike


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
Sent: Friday, March 31, 2023 4:00 PM
To: devel@edk2.groups.io; rebe...@bsdio.com; Ni, Ray 
Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg/Test: Disable random test cases

I'm not sure about the availability of more resources but something like
merge queue might be able to help.

https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-
merges/managing-a-merge-queue

This presentation has an overview -
https://www.youtube.com/watch?v=04TTRJArpVw.

On 3/31/2023 6:08 PM, Rebecca Cran wrote:

I've been wondering, is it possible to increase the parallelism or add
more resources to the CI runner pool?












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

Re: [edk2-devel] [PATCH v1 1/1] .github/dependabot.yml: Disable automatic rebasing

2023-03-31 Thread Sean


reviewed-by: Sean Brogan 


On 3/31/2023 4:48 PM, Michael Kubacki wrote:

From: Michael Kubacki 

Sets the rebase-strategy to "disabled" to prevent automatic
rebasing.

Rebasing can be done manually in the dependabot PR either through
the GitHub UI or the dependabot command.

Cc: Sean Brogan 
Cc: Michael D Kinney 
Signed-off-by: Michael Kubacki 
---
  .github/dependabot.yml | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index b4e0b93b16ca..479440fe6397 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -20,6 +20,7 @@ updates:
- "makubacki"
- "mdkinney"
- "spbrogan"
+rebase-strategy: "disabled"
  
- package-ecosystem: "github-actions"

  directory: "/"
@@ -32,3 +33,4 @@ updates:
- "makubacki"
- "mdkinney"
- "spbrogan"
+rebase-strategy: "disabled"



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

[edk2-devel] [PATCH v1 1/1] .github/dependabot.yml: Disable automatic rebasing

2023-03-31 Thread Michael Kubacki

From: Michael Kubacki 

Sets the rebase-strategy to "disabled" to prevent automatic
rebasing.

Rebasing can be done manually in the dependabot PR either through
the GitHub UI or the dependabot command.

Cc: Sean Brogan 
Cc: Michael D Kinney 
Signed-off-by: Michael Kubacki 
---
 .github/dependabot.yml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.github/dependabot.yml b/.github/dependabot.yml
index b4e0b93b16ca..479440fe6397 100644
--- a/.github/dependabot.yml
+++ b/.github/dependabot.yml
@@ -20,6 +20,7 @@ updates:
   - "makubacki"
   - "mdkinney"
   - "spbrogan"
+rebase-strategy: "disabled"
 
   - package-ecosystem: "github-actions"
 directory: "/"
@@ -32,3 +33,4 @@ updates:
   - "makubacki"
   - "mdkinney"
   - "spbrogan"
+rebase-strategy: "disabled"
-- 
2.40.0.windows.1



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

[edk2-devel] [PATCH] IntelFsp2Pkg: TempRamInit API should preserve EBX/RBX register.

2023-03-31 Thread Chiu, Chasel

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

FSP specification defines the TempRamInit API preserved register list
which including EBX/RBX, however current implementation unexpectedly
overriding EBX/RBX register that should be fixed.

Cc: Nate DeSimone 
Cc: Star Zeng 
Signed-off-by: Chasel Chiu 
---
 IntelFsp2Pkg/FspSecCore/Ia32/SaveRestoreSseNasm.inc |  7 +++
 IntelFsp2Pkg/Include/SaveRestoreSseAvxNasm.inc  | 21 -
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/IntelFsp2Pkg/FspSecCore/Ia32/SaveRestoreSseNasm.inc 
b/IntelFsp2Pkg/FspSecCore/Ia32/SaveRestoreSseNasm.inc
index a222f2e376..016f943b43 100644
--- a/IntelFsp2Pkg/FspSecCore/Ia32/SaveRestoreSseNasm.inc
+++ b/IntelFsp2Pkg/FspSecCore/Ia32/SaveRestoreSseNasm.inc
@@ -157,6 +157,9 @@ NextAddress:
 ; Use CpuId instruction (CPUID.01H:EDX.SSE[bit 25] = 1) to test
 ; whether the processor supports SSE instruction.
 ;
+; Save EBX to MM2
+;
+movdmm2, ebx
 mov eax, 1
 cpuid
 bt  edx, 25
@@ -169,6 +172,10 @@ NextAddress:
 bt  ecx, 19
 jnc SseError
 %endif
+;
+; Restore EBX from MM2
+;
+movdebx, mm2
 
 ;
 ; Set OSFXSR bit (bit #9) & OSXMMEXCPT bit (bit #10)
diff --git a/IntelFsp2Pkg/Include/SaveRestoreSseAvxNasm.inc 
b/IntelFsp2Pkg/Include/SaveRestoreSseAvxNasm.inc
index 38c807a311..002a5a1412 100644
--- a/IntelFsp2Pkg/Include/SaveRestoreSseAvxNasm.inc
+++ b/IntelFsp2Pkg/Include/SaveRestoreSseAvxNasm.inc
@@ -255,6 +255,10 @@ NextAddress:
 ; Use CpuId instruction (CPUID.01H:EDX.SSE[bit 25] = 1) to test
 ; whether the processor supports SSE instruction.
 ;
+; Save RBX to R11
+; Save RCX to R10
+;
+mov r11, rbx
 mov r10, rcx
 mov rax, 1
 cpuid
@@ -266,7 +270,12 @@ NextAddress:
 ;
 bt  ecx, 19
 jnc SseError
-mov rcx,  r10
+;
+; Restore RBX from R11
+; Restore RCX from R10
+;
+mov rbx, r11
+mov rcx, r10
 
 ;
 ; Set OSFXSR bit (bit #9) & OSXMMEXCPT bit (bit #10)
@@ -284,6 +293,11 @@ NextAddress:
 %endmacro
 
 %macro ENABLE_AVX   0
+;
+; Save RBX to R11
+; Save RCX to R10
+;
+mov r11, rbx
 mov r10, rcx
 mov eax, 1
 cpuid
@@ -307,6 +321,11 @@ EnableAvx:
 xgetbv ; result in edx:eax
 or  eax, 0006h ; Set XCR0 bit #1 and bit #2 to enable SSE 
state and AVX state
 xsetbv
+;
+; Restore RBX from R11
+; Restore RCX from R10
+;
+mov rbx, r11
 mov rcx, r10
 %endmacro
 
-- 
2.35.0.windows.1



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

Re: [edk2-devel] [PATCH] UefiCpuPkg/Test: Disable random test cases

2023-03-31 Thread Michael D Kinney

Michael,

I see older PRs from dependabot still running jobs.

Is there a way to configure how often those checks are made?

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
> Sent: Friday, March 31, 2023 4:00 PM
> To: devel@edk2.groups.io; rebe...@bsdio.com; Ni, Ray 
> Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg/Test: Disable random test cases
> 
> I'm not sure about the availability of more resources but something like
> merge queue might be able to help.
> 
> https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-
> merges/managing-a-merge-queue
> 
> This presentation has an overview -
> https://www.youtube.com/watch?v=04TTRJArpVw.
> 
> On 3/31/2023 6:08 PM, Rebecca Cran wrote:
> > I've been wondering, is it possible to increase the parallelism or add
> > more resources to the CI runner pool?
> >
> >
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102336): https://edk2.groups.io/g/devel/message/102336
Mute This Topic: https://groups.io/mt/97979483/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] UefiCpuPkg/Test: Disable random test cases

2023-03-31 Thread Michael Kubacki

I'm not sure about the availability of more resources but something like 
merge queue might be able to help.


https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue

This presentation has an overview - 
https://www.youtube.com/watch?v=04TTRJArpVw.


On 3/31/2023 6:08 PM, Rebecca Cran wrote:
I've been wondering, is it possible to increase the parallelism or add 
more resources to the CI runner pool?






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

[edk2-devel] [PATCH v3] IntelFsp2Pkg: LoadMicrocodeDefault() causing unnecessary delay.

2023-03-31 Thread Chiu, Chasel

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

FSP should support the scenario that CPU microcode already loaded
before calling LoadMicrocodeDefault(), in this case it should return
directly without spending more time.
Also the LoadMicrocodeDefault() should only attempt to load one version
of the microcode for current CPU and return directly without parsing
rest of the microcode in FV.

Cc: Nate DeSimone 
Cc: Star Zeng 
Cc: Ray Ni 
Signed-off-by: Chasel Chiu 
---
 IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm | 26 ++
 IntelFsp2Pkg/FspSecCore/X64/FspApiEntryT.nasm  | 26 ++
 2 files changed, 44 insertions(+), 8 deletions(-)

diff --git a/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm 
b/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm
index 2cff8b3643..79f2a20a2c 100644
--- a/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm
+++ b/IntelFsp2Pkg/FspSecCore/Ia32/FspApiEntryT.nasm
@@ -245,6 +245,22 @@ ASM_PFX(LoadMicrocodeDefault):
cmpesp, 0
jz ParamError
 
+   ;
+   ; If microcode already loaded before this function, exit this function with 
SUCCESS.
+   ;
+   mov   ecx, MSR_IA32_BIOS_SIGN_ID
+   xor   eax, eax   ; Clear EAX
+   xor   edx, edx   ; Clear EDX
+   wrmsr; Load 0 to MSR at 8Bh
+
+   mov   eax, 1
+   cpuid
+   mov   ecx, MSR_IA32_BIOS_SIGN_ID
+   rdmsr ; Get current microcode signature
+   xor   eax, eax
+   test  edx, edx
+   jnz   Exit2
+
; skip loading Microcode if the MicrocodeCodeSize is zero
; and report error if size is less than 2k
; first check UPD header revision
@@ -450,7 +466,7 @@ LoadCheck:
 
; Verify this microcode update is not already loaded
cmp   dword [esi + MicrocodeHdr.MicrocodeHdrRevision], edx
-   jeContinue
+   jeDone ; if already one version microcode loaded, go to done
 
 LoadMicrocode:
; EAX contains the linear address of the start of the Update Data
@@ -465,10 +481,12 @@ LoadMicrocode:
mov   eax, 1
cpuid
 
-Continue:
-   jmp   NextMicrocode
-
 Done:
+   mov   ecx, MSR_IA32_BIOS_SIGN_ID
+   xor   eax, eax   ; Clear EAX
+   xor   edx, edx   ; Clear EDX
+   wrmsr; Load 0 to MSR at 8Bh
+
mov   eax, 1
cpuid
mov   ecx, MSR_IA32_BIOS_SIGN_ID
diff --git a/IntelFsp2Pkg/FspSecCore/X64/FspApiEntryT.nasm 
b/IntelFsp2Pkg/FspSecCore/X64/FspApiEntryT.nasm
index b32fa32a89..3e40678f47 100644
--- a/IntelFsp2Pkg/FspSecCore/X64/FspApiEntryT.nasm
+++ b/IntelFsp2Pkg/FspSecCore/X64/FspApiEntryT.nasm
@@ -141,6 +141,22 @@ ASM_PFX(LoadMicrocodeDefault):
jz ParamError
movrsp, rcx
 
+   ;
+   ; If microcode already loaded before this function, exit this function with 
SUCCESS.
+   ;
+   mov   ecx, MSR_IA32_BIOS_SIGN_ID
+   xor   eax, eax   ; Clear EAX
+   xor   edx, edx   ; Clear EDX
+   wrmsr; Load 0 to MSR at 8Bh
+
+   mov   eax, 1
+   cpuid
+   mov   ecx, MSR_IA32_BIOS_SIGN_ID
+   rdmsr ; Get current microcode signature
+   xor   rax, rax
+   test  edx, edx
+   jnz   Exit2
+
; skip loading Microcode if the MicrocodeCodeSize is zero
; and report error if size is less than 2k
; first check UPD header revision
@@ -291,7 +307,7 @@ LoadCheck:
 
; Verify this microcode update is not already loaded
cmp   dword [esi + MicrocodeHdr.MicrocodeHdrRevision], edx
-   jeContinue
+   jeDone ; if already one version microcode loaded, go to done
 
 LoadMicrocode:
; EAX contains the linear address of the start of the Update Data
@@ -306,10 +322,12 @@ LoadMicrocode:
mov   eax, 1
cpuid
 
-Continue:
-   jmp   NextMicrocode
-
 Done:
+   mov   ecx, MSR_IA32_BIOS_SIGN_ID
+   xor   eax, eax   ; Clear EAX
+   xor   edx, edx   ; Clear EDX
+   wrmsr; Load 0 to MSR at 8Bh
+
mov   eax, 1
cpuid
mov   ecx, MSR_IA32_BIOS_SIGN_ID
-- 
2.35.0.windows.1



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

Re: [edk2-devel] [PATCH] UefiCpuPkg/Test: Disable random test cases

2023-03-31 Thread Rebecca Cran

I've been wondering, is it possible to increase the parallelism or add 
more resources to the CI runner pool?



--
Rebecca Cran


On 3/31/23 12:22 PM, Ni, Ray wrote:

The random test cases just run for too long that may cause timeout
in CI test.
Disable them for now.

Signed-off-by: Ray Ni 
---
  .../UnitTest/CpuPageTableLibUnitTestHost.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c 
b/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
index 547f6c2e50..745b774c66 100644
--- a/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
+++ b/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
@@ -881,11 +881,11 @@ UefiTestMain (
  goto EXIT;
}
  
-  AddTestCase (RandomTestCase, "Random Test for Paging4Level", "Random Test Case1", TestCaseforRandomTest, NULL, NULL, );

-  AddTestCase (RandomTestCase, "Random Test for Paging4Level1G", "Random Test 
Case2", TestCaseforRandomTest, NULL, NULL, );
-  AddTestCase (RandomTestCase, "Random Test for Paging5Level", "Random Test 
Case3", TestCaseforRandomTest, NULL, NULL, );
-  AddTestCase (RandomTestCase, "Random Test for Paging5Level1G", "Random Test 
Case4", TestCaseforRandomTest, NULL, NULL, );
-  AddTestCase (RandomTestCase, "Random Test for PagingPae", "Random Test Case5", 
TestCaseforRandomTest, NULL, NULL, );
+  // AddTestCase (RandomTestCase, "Random Test for Paging4Level", "Random Test 
Case1", TestCaseforRandomTest, NULL, NULL, );
+  // AddTestCase (RandomTestCase, "Random Test for Paging4Level1G", "Random Test 
Case2", TestCaseforRandomTest, NULL, NULL, );
+  // AddTestCase (RandomTestCase, "Random Test for Paging5Level", "Random Test 
Case3", TestCaseforRandomTest, NULL, NULL, );
+  // AddTestCase (RandomTestCase, "Random Test for Paging5Level1G", "Random Test 
Case4", TestCaseforRandomTest, NULL, NULL, );
+  // AddTestCase (RandomTestCase, "Random Test for PagingPae", "Random Test 
Case5", TestCaseforRandomTest, NULL, NULL, );
  
//

// Execute the tests.



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

Re: [edk2-devel] [PATCH v3 1/3] Platform/AMD: Adds MinBoardPkg to support MinPlatformPkg

2023-03-31 Thread Sean

Regardless of directory path I would suggest that all "Packages" have a 
unique and descriptive name.  MinBoardPkg doesn't meet that 
suggestion.   If/when the edk2 CI tools run I would expect problems/odd 
behavior if two packages collide in naming.


Thanks

Sean



On 3/22/2023 11:13 PM, Abdul Lateef Attar via groups.io wrote:

Adds initial DEC and DSC file for MinBoardPkg.
This package provides supporting modules for AMD boards to
leverage MinPlatformPkg framework.

Signed-off-by: Abdul Lateef Attar 
Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Abner Chang 
Cc: Michael D Kinney 
---
  Platform/AMD/MinBoardPkg/MinBoardPkg.dec | 19 +++
  Platform/AMD/MinBoardPkg/MinBoardPkg.dsc | 21 +
  2 files changed, 40 insertions(+)
  create mode 100644 Platform/AMD/MinBoardPkg/MinBoardPkg.dec
  create mode 100644 Platform/AMD/MinBoardPkg/MinBoardPkg.dsc

diff --git a/Platform/AMD/MinBoardPkg/MinBoardPkg.dec 
b/Platform/AMD/MinBoardPkg/MinBoardPkg.dec
new file mode 100644
index ..23d737d196a2
--- /dev/null
+++ b/Platform/AMD/MinBoardPkg/MinBoardPkg.dec
@@ -0,0 +1,19 @@
+## @file MinBoardPkg.dec
+#  Declaration file for AMD's MinBoardPkg.
+#
+#  This package supports AMD processor family based board as per the 
MinPlatform
+#  Arch specification.
+#
+#  Copyright (c) 2023, Advanced Micro Devices, Inc. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#  @par Specification Reference:
+#   -https://tianocore-docs.github.io/edk2-MinimumPlatformSpecification/draft/ 
0.7
+##
+
+[Defines]
+  DEC_SPECIFICATION  = 1.27
+  PACKAGE_NAME   = MinBoardPkg
+  PACKAGE_GUID   = 44F9D761-9ECB-43DD-A5AC-177E5048701B
+  PACKAGE_VERSION= 0.1
+
diff --git a/Platform/AMD/MinBoardPkg/MinBoardPkg.dsc 
b/Platform/AMD/MinBoardPkg/MinBoardPkg.dsc
new file mode 100644
index ..8c120c0649e7
--- /dev/null
+++ b/Platform/AMD/MinBoardPkg/MinBoardPkg.dsc
@@ -0,0 +1,21 @@
+## @file
+#  MinBoardPkg.dsc
+#
+#  Description file for AMD MinBoardPkg
+#
+#  Copyright (c) 2023, Advanced Micro Devices, Inc. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+##
+
+[Defines]
+  DSC_SPECIFICATION   = 1.30
+  PLATFORM_GUID   = 88F8A9AE-2FA0-4D58-A6F9-05F635C05F4E
+  PLATFORM_NAME   = MinBoardPkg
+  PLATFORM_VERSION= 0.1
+  OUTPUT_DIRECTORY= Build/$(PLATFORM_NAME)
+  BUILD_TARGETS   = DEBUG | RELEASE | NOOPT
+  SUPPORTED_ARCHITECTURES = IA32 | X64
+
+[Packages]
+  MinBoardPkg/MinBoardPkg.dec
+



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

Re: [edk2-devel] PR fails due to OVMF time out

2023-03-31 Thread Gerd Hoffmann

On Fri, Mar 31, 2023 at 03:00:37PM +, Ni, Ray wrote:
> Hi,
> I found several of my PRs cannot pass the CI due to OVMF boot timeout.
> e.g.: Mktme fix by niruiyu * Pull Request #4072 * tianocore/edk2 
> (github.com)
> 
> I also one PR from Ard (X64 text reloc fixes by ardbiesheuvel * Pull Request 
> #4216 * tianocore/edk2 
> (github.com)) failed as well.
> 
> But I remember Mike increased the boot timeout from 1min to 2 mins.
> Why does OVMF boot require more time than before?
> 
> Is that because Gerd enabled the SMP 4 boot?

That could be the reason.  It happened to work in my CI test run,
but maybe I was just lucky.

take care,
  Gerd



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

Re: [edk2-devel] [PATCH] UefiCpuPkg/Test: Disable random test cases

2023-03-31 Thread Sean

Thanks Ray.  Lets discuss this style of testing next week at the tools 
and CI meeting.



Reviewed-by: Sean Brogan 


On 3/31/2023 11:22 AM, Ni, Ray wrote:

The random test cases just run for too long that may cause timeout
in CI test.
Disable them for now.

Signed-off-by: Ray Ni 
---
  .../UnitTest/CpuPageTableLibUnitTestHost.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c 
b/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
index 547f6c2e50..745b774c66 100644
--- a/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
+++ b/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
@@ -881,11 +881,11 @@ UefiTestMain (
  goto EXIT;

}

  


-  AddTestCase (RandomTestCase, "Random Test for Paging4Level", "Random Test 
Case1", TestCaseforRandomTest, NULL, NULL, );

-  AddTestCase (RandomTestCase, "Random Test for Paging4Level1G", "Random Test 
Case2", TestCaseforRandomTest, NULL, NULL, );

-  AddTestCase (RandomTestCase, "Random Test for Paging5Level", "Random Test 
Case3", TestCaseforRandomTest, NULL, NULL, );

-  AddTestCase (RandomTestCase, "Random Test for Paging5Level1G", "Random Test 
Case4", TestCaseforRandomTest, NULL, NULL, );

-  AddTestCase (RandomTestCase, "Random Test for PagingPae", "Random Test Case5", 
TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for Paging4Level", "Random Test 
Case1", TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for Paging4Level1G", "Random Test 
Case2", TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for Paging5Level", "Random Test 
Case3", TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for Paging5Level1G", "Random Test 
Case4", TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for PagingPae", "Random Test 
Case5", TestCaseforRandomTest, NULL, NULL, );

  


//

// Execute the tests.




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

Re: [edk2-devel] [PATCH] UefiCpuPkg/Test: Disable random test cases

2023-03-31 Thread Michael Kubacki


Reviewed-by: Michael Kubacki 

On 3/31/2023 2:22 PM, Ni, Ray wrote:

The random test cases just run for too long that may cause timeout
in CI test.
Disable them for now.

Signed-off-by: Ray Ni 
---
  .../UnitTest/CpuPageTableLibUnitTestHost.c | 10 +-
  1 file changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c 
b/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
index 547f6c2e50..745b774c66 100644
--- a/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
+++ b/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
@@ -881,11 +881,11 @@ UefiTestMain (
  goto EXIT;

}

  


-  AddTestCase (RandomTestCase, "Random Test for Paging4Level", "Random Test 
Case1", TestCaseforRandomTest, NULL, NULL, );

-  AddTestCase (RandomTestCase, "Random Test for Paging4Level1G", "Random Test 
Case2", TestCaseforRandomTest, NULL, NULL, );

-  AddTestCase (RandomTestCase, "Random Test for Paging5Level", "Random Test 
Case3", TestCaseforRandomTest, NULL, NULL, );

-  AddTestCase (RandomTestCase, "Random Test for Paging5Level1G", "Random Test 
Case4", TestCaseforRandomTest, NULL, NULL, );

-  AddTestCase (RandomTestCase, "Random Test for PagingPae", "Random Test Case5", 
TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for Paging4Level", "Random Test 
Case1", TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for Paging4Level1G", "Random Test 
Case2", TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for Paging5Level", "Random Test 
Case3", TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for Paging5Level1G", "Random Test 
Case4", TestCaseforRandomTest, NULL, NULL, );

+  // AddTestCase (RandomTestCase, "Random Test for PagingPae", "Random Test 
Case5", TestCaseforRandomTest, NULL, NULL, );

  


//

// Execute the tests.




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

Re: [edk2-devel] [PATCH v1 1/1] OvmfPkg/CI: Revert SMP mode

2023-03-31 Thread Michael Kubacki

There were a couple issues that lengthened the execution time of build 
agents and a number of changes were queued around the same time a few 
hours ago leading to longer queue times.


I know you're trying to reduce the UefiCpuPkg unit test time in your 
patch, that's currently causing UefiCpuPkg host test jobs to take over 
an hour.


Please share if you see anything else.

Thanks,
Michael

On 3/31/2023 12:59 PM, Ni, Ray wrote:


Anyone knows why the job status is "queued" for all the CI jobs?


-Original Message-
From: devel@edk2.groups.io  On Behalf Of Michael
D Kinney
Sent: Saturday, April 1, 2023 12:13 AM
To: devel@edk2.groups.io; mikub...@linux.microsoft.com
Cc: Ard Biesheuvel ; Yao, Jiewen
; Justen, Jordan L ;
Gerd Hoffmann ; Kinney, Michael D

Subject: Re: [edk2-devel] [PATCH v1 1/1] OvmfPkg/CI: Revert SMP mode

Reviewed-by: Michael D Kinney 



-Original Message-
From: devel@edk2.groups.io  On Behalf Of

Michael Kubacki

Sent: Friday, March 31, 2023 9:11 AM
To: devel@edk2.groups.io
Cc: Ard Biesheuvel ; Yao, Jiewen

; Justen, Jordan L

; Gerd Hoffmann ;

Kinney, Michael D 

Subject: [edk2-devel] [PATCH v1 1/1] OvmfPkg/CI: Revert SMP mode

From: Michael Kubacki 

This is causing excessive boot times in the VS2019 IA32/X64 Full
run to shell tasks (> 2 minutes) and blocking all edk2 CI.

This patch removes the change so it can be root caused separately
without blocking other patches unrelated to OVMF.

Reverts f92a9dce10281c103b04d6b38283e0ff1d677b91

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Michael D Kinney 
Signed-off-by: Michael Kubacki 
---
  OvmfPkg/PlatformCI/PlatformBuildLib.py | 1 -
  1 file changed, 1 deletion(-)

diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py

b/OvmfPkg/PlatformCI/PlatformBuildLib.py

index 1ff85fdc24bb..64fca48a7d1d 100644
--- a/OvmfPkg/PlatformCI/PlatformBuildLib.py
+++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py
@@ -196,7 +196,6 @@ class PlatformBuilder( UefiBuilder,

BuildSettingsManager):

  args  = "-debugcon stdio"   # 
write messages to

stdio

  args += " -global isa-debugcon.iobase=0x402"# 
debug

messages out thru virtual io port

  args += " -net none"# 
turn off network
-args += " -smp 4"
  args += f" -drive file=fat:rw:{VirtualDrive},format=raw,media=disk" #

Mount disk with startup.nsh


  if (self.env.GetValue("QEMU_HEADLESS").upper() == "TRUE"):
--
2.40.0.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102321):

https://edk2.groups.io/g/devel/message/102321

Mute This Topic: https://groups.io/mt/97976680/1643496
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub

[michael.d.kin...@intel.com]

-=-=-=-=-=-=

















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

Re: [edk2-devel] [PATCH] UefiCpuPkg/Test: Disable random test cases

2023-03-31 Thread Ni, Ray




> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ni, Ray
> Sent: Saturday, April 1, 2023 2:22 AM
> To: devel@edk2.groups.io
> Subject: [edk2-devel] [PATCH] UefiCpuPkg/Test: Disable random test cases
> 
> The random test cases just run for too long that may cause timeout
> in CI test.
> Disable them for now.
> 
> Signed-off-by: Ray Ni 
> ---
>  .../UnitTest/CpuPageTableLibUnitTestHost.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git
> a/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTest
> Host.c
> b/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTest
> Host.c
> index 547f6c2e50..745b774c66 100644
> ---
> a/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTest
> Host.c
> +++
> b/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTest
> Host.c
> @@ -881,11 +881,11 @@ UefiTestMain (
>  goto EXIT;
> 
>}
> 
> 
> 
> -  AddTestCase (RandomTestCase, "Random Test for Paging4Level",
> "Random Test Case1", TestCaseforRandomTest, NULL, NULL,
> );
> 
> -  AddTestCase (RandomTestCase, "Random Test for Paging4Level1G",
> "Random Test Case2", TestCaseforRandomTest, NULL, NULL,
> );
> 
> -  AddTestCase (RandomTestCase, "Random Test for Paging5Level",
> "Random Test Case3", TestCaseforRandomTest, NULL, NULL,
> );
> 
> -  AddTestCase (RandomTestCase, "Random Test for Paging5Level1G",
> "Random Test Case4", TestCaseforRandomTest, NULL, NULL,
> );
> 
> -  AddTestCase (RandomTestCase, "Random Test for PagingPae", "Random
> Test Case5", TestCaseforRandomTest, NULL, NULL,
> );
> 
> +  // AddTestCase (RandomTestCase, "Random Test for Paging4Level",
> "Random Test Case1", TestCaseforRandomTest, NULL, NULL,
> );
> 
> +  // AddTestCase (RandomTestCase, "Random Test for Paging4Level1G",
> "Random Test Case2", TestCaseforRandomTest, NULL, NULL,
> );
> 
> +  // AddTestCase (RandomTestCase, "Random Test for Paging5Level",
> "Random Test Case3", TestCaseforRandomTest, NULL, NULL,
> );
> 
> +  // AddTestCase (RandomTestCase, "Random Test for Paging5Level1G",
> "Random Test Case4", TestCaseforRandomTest, NULL, NULL,
> );
> 
> +  // AddTestCase (RandomTestCase, "Random Test for PagingPae",
> "Random Test Case5", TestCaseforRandomTest, NULL, NULL,
> );
> 
> 
> 
>//
> 
>// Execute the tests.
> 
> --
> 2.39.1.windows.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#102326):
> https://edk2.groups.io/g/devel/message/102326
> Mute This Topic: https://groups.io/mt/97979483/1712937
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe:
> https://edk2.groups.io/g/devel/leave/3759105/1712937/893644498/xyzzy
> [ray...@intel.com]
> -=-=-=-=-=-=
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102327): https://edk2.groups.io/g/devel/message/102327
Mute This Topic: https://groups.io/mt/97979483/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] [PATCH] UefiCpuPkg/Test: Disable random test cases

2023-03-31 Thread Ni, Ray

The random test cases just run for too long that may cause timeout
in CI test.
Disable them for now.

Signed-off-by: Ray Ni 
---
 .../UnitTest/CpuPageTableLibUnitTestHost.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c 
b/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
index 547f6c2e50..745b774c66 100644
--- a/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
+++ b/UefiCpuPkg/Library/CpuPageTableLib/UnitTest/CpuPageTableLibUnitTestHost.c
@@ -881,11 +881,11 @@ UefiTestMain (
 goto EXIT;
   }
 
-  AddTestCase (RandomTestCase, "Random Test for Paging4Level", "Random Test 
Case1", TestCaseforRandomTest, NULL, NULL, );
-  AddTestCase (RandomTestCase, "Random Test for Paging4Level1G", "Random Test 
Case2", TestCaseforRandomTest, NULL, NULL, );
-  AddTestCase (RandomTestCase, "Random Test for Paging5Level", "Random Test 
Case3", TestCaseforRandomTest, NULL, NULL, );
-  AddTestCase (RandomTestCase, "Random Test for Paging5Level1G", "Random Test 
Case4", TestCaseforRandomTest, NULL, NULL, );
-  AddTestCase (RandomTestCase, "Random Test for PagingPae", "Random Test 
Case5", TestCaseforRandomTest, NULL, NULL, );
+  // AddTestCase (RandomTestCase, "Random Test for Paging4Level", "Random Test 
Case1", TestCaseforRandomTest, NULL, NULL, );
+  // AddTestCase (RandomTestCase, "Random Test for Paging4Level1G", "Random 
Test Case2", TestCaseforRandomTest, NULL, NULL, );
+  // AddTestCase (RandomTestCase, "Random Test for Paging5Level", "Random Test 
Case3", TestCaseforRandomTest, NULL, NULL, );
+  // AddTestCase (RandomTestCase, "Random Test for Paging5Level1G", "Random 
Test Case4", TestCaseforRandomTest, NULL, NULL, );
+  // AddTestCase (RandomTestCase, "Random Test for PagingPae", "Random Test 
Case5", TestCaseforRandomTest, NULL, NULL, );
 
   //
   // Execute the tests.
-- 
2.39.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102326): https://edk2.groups.io/g/devel/message/102326
Mute This Topic: https://groups.io/mt/97979483/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] [PATCH] add ArmCpuInfo EFI application

2023-03-31 Thread Marcin Juszkiewicz

App goes through ID_AA64*_EL1 system registers and decode their values.

First version which does not use much of current AArch64 support code
present in EDK2. Written to check what data is there and what can be
done with it.
---
 .../Application/ArmCpuInfo/ArmCpuInfo.c   | 2277 +
 .../Application/ArmCpuInfo/ArmCpuInfo.inf |   38 +
 .../Application/ArmCpuInfo/readargs.h |   12 +
 .../Application/ArmCpuInfo/readregs.s |   49 +
 MdeModulePkg/MdeModulePkg.dsc |3 +-
 5 files changed, 2378 insertions(+), 1 deletion(-)
 create mode 100644 MdeModulePkg/Application/ArmCpuInfo/ArmCpuInfo.c
 create mode 100644 MdeModulePkg/Application/ArmCpuInfo/ArmCpuInfo.inf
 create mode 100644 MdeModulePkg/Application/ArmCpuInfo/readargs.h
 create mode 100644 MdeModulePkg/Application/ArmCpuInfo/readregs.s

diff --git a/MdeModulePkg/Application/ArmCpuInfo/ArmCpuInfo.c 
b/MdeModulePkg/Application/ArmCpuInfo/ArmCpuInfo.c
new file mode 100644
index 00..79a02ae430
--- /dev/null
+++ b/MdeModulePkg/Application/ArmCpuInfo/ArmCpuInfo.c
@@ -0,0 +1,2277 @@
+/** @file
+
+  Copyright (c) 2023 Marcin Juszkiewicz
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+ **/
+
+#include 
+#include 
+#include "readargs.h"
+
+bool sve_present = false;
+bool sme_present = false;
+
+void print_text(const char* field, const char* bits, const char* value, const 
char* description)
+{
+   AsciiPrint(" %-16a | %5a | %5a | %a\n", field, bits, value, 
description);
+}
+
+void print_values(const char* field, const char* bits, const int value, const 
char* description)
+{
+   char binaries[17][5] = {"", "0001", "0010", "0011", "0100", "0101", 
"0110", "0111",
+   "1000", "1001", "1010", "1011", "1100", "1101", 
"1110", ""};
+
+   AsciiPrint(" %-16a | %5a | %5a | %a\n", field, bits, binaries[value], 
description);
+}
+
+void print_spacer(void)
+{
+   
AsciiPrint("--|---|---|--\n");
+}
+
+void handle_aa64mmfr0_el1(const UINT64 aa64mmfr0_el1)
+{
+   UINT64 value;
+   char* regname = "ID_AA64MMFR0_EL1";
+   char* description;
+   char* bits;
+
+
+   bits = "3:0 ";
+   value = aa64mmfr0_el1 & 0xf;
+   switch(value)
+   {
+   case 0b:
+   description = "32 bits (4GB) of physical address range 
supported.";
+   break;
+   case 0b0001:
+   description = "36 bits (64GB) of physical address range 
supported.";
+   break;
+   case 0b0010:
+   description = "40 bits (1TB) of physical address range 
supported.";
+   break;
+   case 0b0011:
+   description = "42 bits (4TB) of physical address range 
supported.";
+   break;
+   case 0b0100:
+   description = "44 bits (16TB) of physical address range 
supported.";
+   break;
+   case 0b0101:
+   description = "48 bits (256TB) of physical address 
range supported.";
+   break;
+   case 0b0110:
+   description = "52 bits (4PB) of physical address range 
supported.";
+   break;
+   default:
+   description = "unknown";
+   break;
+   }
+   print_values(regname, bits, value, description);
+   if(value == 0b0110)
+   print_text("", "", "", "FEAT_LPA implemented.");
+
+
+   bits = "7:4 ";
+   value = (aa64mmfr0_el1 >>  4) & 0xf;
+   switch(value)
+   {
+   case 0b:
+   description = "ASID: 8 bits";
+   break;
+   case 0b0010:
+   description = "ASID: 16 bits";
+   break;
+   default:
+   description = "unknown";
+   break;
+   }
+   print_values(regname, bits, value, description);
+
+   bits = "11:8 ";
+   value = (aa64mmfr0_el1 >>  8) & 0xf;
+   switch(value)
+   {
+   case 0b:
+   description = "No mixed-endian support.";
+   break;
+   case 0b0001:
+   description = "Mixed-endian support.";
+   break;
+   default:
+   description = "unknown";
+   break;
+   }
+   print_values(regname, bits, value, description);
+
+   // only valid for BigEnd != 0b
+   if( ((aa64mmfr0_el1 >>  8) & 0xf) != 0b )
+   {
+   if( ((aa64mmfr0_el1 >> 16) & 0xf) == 0b )
+   {
+   print_values("ID_AA64MMFR0_EL1", "19:16", 
0b, "No mixed-endian support at EL0.");
+

Re: [edk2-devel] [PATCH v1 1/1] OvmfPkg/CI: Revert SMP mode

2023-03-31 Thread Ni, Ray


Anyone knows why the job status is "queued" for all the CI jobs?

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael
> D Kinney
> Sent: Saturday, April 1, 2023 12:13 AM
> To: devel@edk2.groups.io; mikub...@linux.microsoft.com
> Cc: Ard Biesheuvel ; Yao, Jiewen
> ; Justen, Jordan L ;
> Gerd Hoffmann ; Kinney, Michael D
> 
> Subject: Re: [edk2-devel] [PATCH v1 1/1] OvmfPkg/CI: Revert SMP mode
> 
> Reviewed-by: Michael D Kinney 
> 
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of
> Michael Kubacki
> > Sent: Friday, March 31, 2023 9:11 AM
> > To: devel@edk2.groups.io
> > Cc: Ard Biesheuvel ; Yao, Jiewen
> ; Justen, Jordan L
> > ; Gerd Hoffmann ;
> Kinney, Michael D 
> > Subject: [edk2-devel] [PATCH v1 1/1] OvmfPkg/CI: Revert SMP mode
> >
> > From: Michael Kubacki 
> >
> > This is causing excessive boot times in the VS2019 IA32/X64 Full
> > run to shell tasks (> 2 minutes) and blocking all edk2 CI.
> >
> > This patch removes the change so it can be root caused separately
> > without blocking other patches unrelated to OVMF.
> >
> > Reverts f92a9dce10281c103b04d6b38283e0ff1d677b91
> >
> > Cc: Ard Biesheuvel 
> > Cc: Jiewen Yao 
> > Cc: Jordan Justen 
> > Cc: Gerd Hoffmann 
> > Cc: Michael D Kinney 
> > Signed-off-by: Michael Kubacki 
> > ---
> >  OvmfPkg/PlatformCI/PlatformBuildLib.py | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> > index 1ff85fdc24bb..64fca48a7d1d 100644
> > --- a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> > +++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> > @@ -196,7 +196,6 @@ class PlatformBuilder( UefiBuilder,
> BuildSettingsManager):
> >  args  = "-debugcon stdio"  
> >  # write messages to
> stdio
> >  args += " -global isa-debugcon.iobase=0x402"   
> >  # debug
> messages out thru virtual io port
> >  args += " -net none"   
> >  # turn off network
> > -args += " -smp 4"
> >  args += f" -drive 
> > file=fat:rw:{VirtualDrive},format=raw,media=disk" #
> Mount disk with startup.nsh
> >
> >  if (self.env.GetValue("QEMU_HEADLESS").upper() == "TRUE"):
> > --
> > 2.40.0.windows.1
> >
> >
> >
> > -=-=-=-=-=-=
> > Groups.io Links: You receive all messages sent to this group.
> > View/Reply Online (#102321):
> https://edk2.groups.io/g/devel/message/102321
> > Mute This Topic: https://groups.io/mt/97976680/1643496
> > Group Owner: devel+ow...@edk2.groups.io
> > Unsubscribe: https://edk2.groups.io/g/devel/unsub
> [michael.d.kin...@intel.com]
> > -=-=-=-=-=-=
> >
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102324): https://edk2.groups.io/g/devel/message/102324
Mute This Topic: https://groups.io/mt/97976680/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 v1 1/1] OvmfPkg/CI: Revert SMP mode

2023-03-31 Thread Michael D Kinney

Reviewed-by: Michael D Kinney 


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Michael Kubacki
> Sent: Friday, March 31, 2023 9:11 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Yao, Jiewen 
> ; Justen, Jordan L
> ; Gerd Hoffmann ; Kinney, 
> Michael D 
> Subject: [edk2-devel] [PATCH v1 1/1] OvmfPkg/CI: Revert SMP mode
> 
> From: Michael Kubacki 
> 
> This is causing excessive boot times in the VS2019 IA32/X64 Full
> run to shell tasks (> 2 minutes) and blocking all edk2 CI.
> 
> This patch removes the change so it can be root caused separately
> without blocking other patches unrelated to OVMF.
> 
> Reverts f92a9dce10281c103b04d6b38283e0ff1d677b91
> 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Gerd Hoffmann 
> Cc: Michael D Kinney 
> Signed-off-by: Michael Kubacki 
> ---
>  OvmfPkg/PlatformCI/PlatformBuildLib.py | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py 
> b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> index 1ff85fdc24bb..64fca48a7d1d 100644
> --- a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> +++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> @@ -196,7 +196,6 @@ class PlatformBuilder( UefiBuilder, BuildSettingsManager):
>  args  = "-debugcon stdio"   
> # write messages to stdio
>  args += " -global isa-debugcon.iobase=0x402"
> # debug messages out thru virtual io port
>  args += " -net none"
> # turn off network
> -args += " -smp 4"
>  args += f" -drive file=fat:rw:{VirtualDrive},format=raw,media=disk" 
> # Mount disk with startup.nsh
> 
>  if (self.env.GetValue("QEMU_HEADLESS").upper() == "TRUE"):
> --
> 2.40.0.windows.1
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#102321): https://edk2.groups.io/g/devel/message/102321
> Mute This Topic: https://groups.io/mt/97976680/1643496
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [michael.d.kin...@intel.com]
> -=-=-=-=-=-=
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102323): https://edk2.groups.io/g/devel/message/102323
Mute This Topic: https://groups.io/mt/97976680/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 v1 1/1] OvmfPkg/CI: Revert SMP mode

2023-03-31 Thread Ard Biesheuvel

On Fri, 31 Mar 2023 at 18:11, Michael Kubacki
 wrote:
>
> From: Michael Kubacki 
>
> This is causing excessive boot times in the VS2019 IA32/X64 Full
> run to shell tasks (> 2 minutes) and blocking all edk2 CI.
>
> This patch removes the change so it can be root caused separately
> without blocking other patches unrelated to OVMF.
>
> Reverts f92a9dce10281c103b04d6b38283e0ff1d677b91
>
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Gerd Hoffmann 
> Cc: Michael D Kinney 
> Signed-off-by: Michael Kubacki 
> ---
>  OvmfPkg/PlatformCI/PlatformBuildLib.py | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py 
> b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> index 1ff85fdc24bb..64fca48a7d1d 100644
> --- a/OvmfPkg/PlatformCI/PlatformBuildLib.py
> +++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py
> @@ -196,7 +196,6 @@ class PlatformBuilder( UefiBuilder, BuildSettingsManager):
>  args  = "-debugcon stdio"   
> # write messages to stdio
>  args += " -global isa-debugcon.iobase=0x402"
> # debug messages out thru virtual io port
>  args += " -net none"
> # turn off network
> -args += " -smp 4"
>  args += f" -drive file=fat:rw:{VirtualDrive},format=raw,media=disk" 
> # Mount disk with startup.nsh
>
>  if (self.env.GetValue("QEMU_HEADLESS").upper() == "TRUE"):

Thanks for the fixed

Queued up as #4220


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

[edk2-devel] [PATCH v1 1/1] OvmfPkg/CI: Revert SMP mode

2023-03-31 Thread Michael Kubacki

From: Michael Kubacki 

This is causing excessive boot times in the VS2019 IA32/X64 Full
run to shell tasks (> 2 minutes) and blocking all edk2 CI.

This patch removes the change so it can be root caused separately
without blocking other patches unrelated to OVMF.

Reverts f92a9dce10281c103b04d6b38283e0ff1d677b91

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Michael D Kinney 
Signed-off-by: Michael Kubacki 
---
 OvmfPkg/PlatformCI/PlatformBuildLib.py | 1 -
 1 file changed, 1 deletion(-)

diff --git a/OvmfPkg/PlatformCI/PlatformBuildLib.py 
b/OvmfPkg/PlatformCI/PlatformBuildLib.py
index 1ff85fdc24bb..64fca48a7d1d 100644
--- a/OvmfPkg/PlatformCI/PlatformBuildLib.py
+++ b/OvmfPkg/PlatformCI/PlatformBuildLib.py
@@ -196,7 +196,6 @@ class PlatformBuilder( UefiBuilder, BuildSettingsManager):
 args  = "-debugcon stdio"   # 
write messages to stdio
 args += " -global isa-debugcon.iobase=0x402"# 
debug messages out thru virtual io port
 args += " -net none"# 
turn off network
-args += " -smp 4"
 args += f" -drive file=fat:rw:{VirtualDrive},format=raw,media=disk" # 
Mount disk with startup.nsh
 
 if (self.env.GetValue("QEMU_HEADLESS").upper() == "TRUE"):
-- 
2.40.0.windows.1



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

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

2023-03-31 Thread Marvin Häuser

> On 31. Mar 2023, at 16:58, Rebecca Cran  wrote:
> 
> On 3/31/23 2:29 AM, Marvin Häuser wrote:
>> I agree if there’s an actual plan on doing that. We depend on XCODE5 
>> downstream, but I think it would literally be easier for us if the upstream 
>> version was dropped than rebasing against hacks that our slightly modded 
>> variant does not require.
>> 
>> Cc Andrew and Rebecca. I don’t know anyone else who might still be using 
>> XCODE5. Any objections to dropping it? If so, any plans to pick up my 
>> proposed changes instead?
> 
> I've only been using XCODE5 to test if it still works. I do all of my 
> development work on Linux or FreeBSD.

I checked the list and most of the traffic regarding XCODE5 is basically Andrew 
and you. So if you don't need this toolchain...

@Andrew Would you agree it's fair for Apple to maintain XCODE5 and its oddities 
downstream? I know someone mentioned the ARM transition, but I think you still 
support UEFI for HV things, don't you? The alternative would be we revamp the 
upstream XCODE5 toolchain and mtoc with our changes from AUDK and ocmtoc, but 
this isn't feasible without strong support from Apple (our previous patches to 
mtoc were ignored). I don't think the burden easily fixable XCODE5 oddities put 
on the general codebase are acceptable going forward. Thanks!

Best regards,
Marvin

> 
> 
> -- 
> 
> Rebecca Cran
> 
> 

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

[edk2-devel] PR fails due to OVMF time out

2023-03-31 Thread Ni, Ray

Hi,
I found several of my PRs cannot pass the CI due to OVMF boot timeout.
e.g.: Mktme fix by niruiyu * Pull Request #4072 * tianocore/edk2 
(github.com)

I also one PR from Ard (X64 text reloc fixes by ardbiesheuvel * Pull Request 
#4216 * tianocore/edk2 
(github.com)) failed as well.

But I remember Mike increased the boot timeout from 1min to 2 mins.
Why does OVMF boot require more time than before?

Is that because Gerd enabled the SMP 4 boot?

Thanks,
Ray


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102319): https://edk2.groups.io/g/devel/message/102319
Mute This Topic: https://groups.io/mt/97975047/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 2/3] BaseTools/Conf/tools_def: Fix CLANGDWARF_IA32_X64

2023-03-31 Thread Marvin Häuser


> On 31. Mar 2023, at 16:41, Ni, Ray  wrote:
> 
> Why ELF header overflows into .text section?

That's a good question, isn't it? :)

>From what I can see, these binaries don't pass post-processing like GenFw or 
>such. GCC (and I think thus CLANGDWARF?) gets an extra objcopy step as part of 
>linking [2], but the arguments are empty [3] and thus should be no-op (I 
>hope?).

I suppose potential candidates are:

1) A bug in the LLD linker used by CLANGDWARF for IA32 and X64. That would be 
very surprising to me, especially as no other platform reported issues and LLD 
is well-established. But who knows, generally ELFs will have large alignment 
values compared to the 64 Bytes used by edk2.

2) A bug in llvm-objcopy used by UniversalPayloadBuild.py [1]. I'm honestly 
unfamiliar with objcopy variants and their quality/reliability.

3) A bug in the llvm-objcopy or CLANGDWARF tools_def commands on the edk2 side 
of things.

Some may disagree, but I would reduce 3) to either 1) or 2). I think even if 
the commands malformed and this causes the overflow, I believe LLD or objcopy 
should issue a warning regardless.

As I have no way to reproduce the issue, I cannot really help further, sorry.

Best regards,
Marvin

[1]
https://github.com/tianocore/edk2/blob/b08a19eae28e76fb5a296a604c27d06fab29b08a/UefiPayloadPkg/UniversalPayloadBuild.py#L163-L183

[2]
https://github.com/tianocore/edk2/blob/b08a19eae28e76fb5a296a604c27d06fab29b08a/BaseTools/Conf/build_rule.template#L298

[3]
https://github.com/tianocore/edk2/blob/b08a19eae28e76fb5a296a604c27d06fab29b08a/BaseTools/Conf/tools_def.template#L2895
https://github.com/tianocore/edk2/blob/b08a19eae28e76fb5a296a604c27d06fab29b08a/BaseTools/Conf/tools_def.template#L2931

> 
>> -Original Message-
>> From: Patrick Rudolph 
>> Sent: Friday, March 17, 2023 10:06 PM
>> Cc: devel@edk2.groups.io; Dong, Guo ; Guo, Gua
>> ; Lu, James ; Ni, Ray
>> ; mhaeu...@posteo.de; a...@kernel.org
>> Subject: [PATCH 2/3] BaseTools/Conf/tools_def: Fix
>> CLANGDWARF_IA32_X64
>> 
>> Drop the "-z max-page-size=0x40" option as it causes the ELF
>> header to overflow into the .text section, causing undefined
>> behaviour.
>> 
>> With high optimization level it corrupts essential code and
>> the binary would crash. It might work with low optimization
>> level though. As the default is to use Oz and LTO, it always
>> crashes.
>> 
>> Test:
>> The ELF generated by
>> 'python UefiPayloadPkg/UniversalPayloadBuild.py -a IA32' boots.
>> 
>> Signed-off-by: Patrick Rudolph 
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4357
>> ---
>> BaseTools/Conf/tools_def.template | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/BaseTools/Conf/tools_def.template
>> b/BaseTools/Conf/tools_def.template
>> index 9b59bd75c3..0c584ab390 100755
>> --- a/BaseTools/Conf/tools_def.template
>> +++ b/BaseTools/Conf/tools_def.template
>> @@ -2866,7 +2866,7 @@ DEFINE CLANGDWARF_X64_PREFIX=
>> ENV(CLANG_BIN)
>> 
>> 
>> # LLVM/CLANG doesn't support -n link option. So, it can't share the same
>> IA32_X64_DLINK_COMMON flag.
>> 
>> # LLVM/CLANG doesn't support common page size. So, it can't share the
>> same GccBase.lds script.
>> 
>> -DEFINE CLANGDWARF_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-q,--gc-
>> sections -z max-page-size=0x40
>> 
>> +DEFINE CLANGDWARF_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-q,--
>> gc-sections
>> 
>> DEFINE CLANGDWARF_DLINK2_FLAGS_COMMON = -Wl,--
>> script=$(EDK_TOOLS_PATH)/Scripts/ClangBase.lds
>> 
>> DEFINE CLANGDWARF_IA32_X64_ASLDLINK_FLAGS =
>> DEF(CLANGDWARF_IA32_X64_DLINK_COMMON) -Wl,--
>> defsym=PECOFF_HEADER_SIZE=0
>> DEF(CLANGDWARF_DLINK2_FLAGS_COMMON) -Wl,--
>> entry,ReferenceAcpiTable -u ReferenceAcpiTable
>> 
>> DEFINE CLANGDWARF_IA32_X64_DLINK_FLAGS=
>> DEF(CLANGDWARF_IA32_X64_DLINK_COMMON) -Wl,--
>> entry,$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Wl,-
>> Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map,--whole-archive
>> 
>> --
>> 2.39.1
> 



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

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

2023-03-31 Thread Rebecca Cran


On 3/31/23 2:29 AM, Marvin Häuser wrote:

I agree if there’s an actual plan on doing that. We depend on XCODE5 
downstream, but I think it would literally be easier for us if the upstream 
version was dropped than rebasing against hacks that our slightly modded 
variant does not require.

Cc Andrew and Rebecca. I don’t know anyone else who might still be using 
XCODE5. Any objections to dropping it? If so, any plans to pick up my proposed 
changes instead?


I've only been using XCODE5 to test if it still works. I do all of my 
development work on Linux or FreeBSD.



--

Rebecca Cran




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

Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/PlatformPei: Skip PlatformInitEmuVariableNvStore in SEV guest

2023-03-31 Thread joeyli via groups.io

On Fri, Mar 31, 2023 at 10:25:09AM +0200, Gerd Hoffmann wrote:
> On Fri, Mar 31, 2023 at 03:59:56PM +0800, joeyli wrote:
> > Hi Gerd,
> > 
> > On Thu, Mar 30, 2023 at 09:50:53AM +0200, Gerd Hoffmann wrote:
> > > On Wed, Mar 29, 2023 at 01:23:10PM +0800, Min Xu wrote:
> > > > From: Min M Xu 
> > > > 
> > > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4379
> > > > 
> > > > PlatformInitEmuVariableNvStore is called to initialize the
> > > > EmuVariableNvStore with the content pointed by
> > > > PcdOvmfFlashNvStorageVariableBase. This is because when OVMF is launched
> > > > with -bios parameter, UEFI variables will be partially emulated, and
> > > > non-volatile variables may lose their contents after a reboot. This 
> > > > makes
> > > > the secure boot feature not working.
> > > > 
> > > > But in SEV guest, this design doesn't work. Because at this point the
> > > > variable store mapping is still private/encrypted, OVMF will see
> > > > ciphertext. So we skip the call of PlatformInitEmuVariableNvStore in
> > > > SEV guest.
> > > 
> > > I'd suggest to simply build without -D SECURE_BOOT_ENABLE instead.
> > > Without initializing the emu var store you will not get a functional
> > > secure boot setup anyway.
> > 
> > In our case, we already shipped ovmf with -D SECURE_BOOT_ENABLE in a couple
> > of versions. Removing it will causes problem in VM live migration.
> 
> Hmm?  qemu live-migrates the rom image too.  Only after poweroff and
> reboot the guest will see an updated firmware image.
>

Thanks for your explanation. Understood.
 
> > I will prefer Min M's solution, until SEV experts found better
> > solution.
> 
> I'd prefer to not poke holes into secure boot.  Re-Initializing the emu
> var store from rom on each reset is also needed for security reasons in
> case the efi variable store is not in smm-protected flash memory.
>

I agree that the efi variable store is not secure without smm. But after
58eb8517ad7b be introduced, the -D SECURE_BOOT_ENABLE doesn't work with
SEV. System just hangs in "NvVarStore FV headers were invalid."

If secure boot can not work with SEV (even it is not really secure), why
not just block the building process when SEV with SECURE_BOOT_ENABLE? At
least the issue will not happen at runtime.

Thanks 
Joey Lee



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

Re: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify CpuExceptionHandlerLib

2023-03-31 Thread Marvin Häuser


> On 31. Mar 2023, at 16:39, Ni, Ray  wrote:
> 
> 
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Marvin
>> Häuser
>> Sent: Friday, March 31, 2023 7:10 PM
>> To: Ard Biesheuvel 
>> Cc: Ni, Ray ; devel@edk2.groups.io; Andrew Fish
>> ; Kinney, Michael D ; Liu,
>> Zhiguang ; Rebecca Cran ;
>> Tom Lendacky 
>> Subject: Re: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify
>> CpuExceptionHandlerLib
>> 
>> 
>>> On 31. Mar 2023, at 13:03, Ard Biesheuvel  wrote:
>>> 
>>> On Fri, 31 Mar 2023 at 12:41, Marvin Häuser  wrote:
 
 Hi Ray,
 
>> On 31. Mar 2023, at 12:09, Ni, Ray  wrote:
> 
> Ard,
> What does "-read_only_relocs suppress" control?
 
 It controls whether relocs that target read-only segments yield a build
>> error or not. I think lld uses “-z notext”.
 
> Linker doesn't produce relocation entries that modifies .text section
>> silently
> so the final .text just cannot run at all?
 
 Could you please rephrase? I’m not sure I understand, but I think it’s
>> important everyone understands the issues at play to make a good judgment
>> call.
 
>>> 
>>> As *I* understood it, it means suppress the *warning* not suppress the
>>> *relocation*
> 
> What the meaning of "suppress relocation"?

The option naming is just a bit odd, it suppresses the warning about 
relocations to read-only segments, not the relocations themselves.

> Why the final binaries are not executable?

I explained that here: https://edk2.groups.io/g/devel/message/102219

TL;dr: Relocations are relative to the first writable segment (thus usually 
__DATA), so relocations to preceding segments (usually __TEXT) will underflow 
and thus get corrupted offsets.

Best regards,
Marvin

> 
>> 
>> Correct.
>> 
>>> 
>>> But the resulting binaries are broken, so it doesn't really matter.
>> 
>> 
>> 
>> 
>> 
> 



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

Re: [edk2-devel] [PATCH 2/3] BaseTools/Conf/tools_def: Fix CLANGDWARF_IA32_X64

2023-03-31 Thread Ni, Ray

Why ELF header overflows into .text section?

> -Original Message-
> From: Patrick Rudolph 
> Sent: Friday, March 17, 2023 10:06 PM
> Cc: devel@edk2.groups.io; Dong, Guo ; Guo, Gua
> ; Lu, James ; Ni, Ray
> ; mhaeu...@posteo.de; a...@kernel.org
> Subject: [PATCH 2/3] BaseTools/Conf/tools_def: Fix
> CLANGDWARF_IA32_X64
> 
> Drop the "-z max-page-size=0x40" option as it causes the ELF
> header to overflow into the .text section, causing undefined
> behaviour.
> 
> With high optimization level it corrupts essential code and
> the binary would crash. It might work with low optimization
> level though. As the default is to use Oz and LTO, it always
> crashes.
> 
> Test:
> The ELF generated by
> 'python UefiPayloadPkg/UniversalPayloadBuild.py -a IA32' boots.
> 
> Signed-off-by: Patrick Rudolph 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4357
> ---
>  BaseTools/Conf/tools_def.template | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> index 9b59bd75c3..0c584ab390 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -2866,7 +2866,7 @@ DEFINE CLANGDWARF_X64_PREFIX=
> ENV(CLANG_BIN)
> 
> 
>  # LLVM/CLANG doesn't support -n link option. So, it can't share the same
> IA32_X64_DLINK_COMMON flag.
> 
>  # LLVM/CLANG doesn't support common page size. So, it can't share the
> same GccBase.lds script.
> 
> -DEFINE CLANGDWARF_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-q,--gc-
> sections -z max-page-size=0x40
> 
> +DEFINE CLANGDWARF_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-q,--
> gc-sections
> 
>  DEFINE CLANGDWARF_DLINK2_FLAGS_COMMON = -Wl,--
> script=$(EDK_TOOLS_PATH)/Scripts/ClangBase.lds
> 
>  DEFINE CLANGDWARF_IA32_X64_ASLDLINK_FLAGS =
> DEF(CLANGDWARF_IA32_X64_DLINK_COMMON) -Wl,--
> defsym=PECOFF_HEADER_SIZE=0
> DEF(CLANGDWARF_DLINK2_FLAGS_COMMON) -Wl,--
> entry,ReferenceAcpiTable -u ReferenceAcpiTable
> 
>  DEFINE CLANGDWARF_IA32_X64_DLINK_FLAGS=
> DEF(CLANGDWARF_IA32_X64_DLINK_COMMON) -Wl,--
> entry,$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Wl,-
> Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map,--whole-archive
> 
> --
> 2.39.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102314): https://edk2.groups.io/g/devel/message/102314
Mute This Topic: https://groups.io/mt/97673649/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] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify CpuExceptionHandlerLib

2023-03-31 Thread Ni, Ray



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Marvin
> Häuser
> Sent: Friday, March 31, 2023 7:10 PM
> To: Ard Biesheuvel 
> Cc: Ni, Ray ; devel@edk2.groups.io; Andrew Fish
> ; Kinney, Michael D ; Liu,
> Zhiguang ; Rebecca Cran ;
> Tom Lendacky 
> Subject: Re: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify
> CpuExceptionHandlerLib
> 
> 
> > On 31. Mar 2023, at 13:03, Ard Biesheuvel  wrote:
> >
> > On Fri, 31 Mar 2023 at 12:41, Marvin Häuser  wrote:
> >>
> >> Hi Ray,
> >>
>  On 31. Mar 2023, at 12:09, Ni, Ray  wrote:
> >>>
> >>> Ard,
> >>> What does "-read_only_relocs suppress" control?
> >>
> >> It controls whether relocs that target read-only segments yield a build
> error or not. I think lld uses “-z notext”.
> >>
> >>> Linker doesn't produce relocation entries that modifies .text section
> silently
> >>> so the final .text just cannot run at all?
> >>
> >> Could you please rephrase? I’m not sure I understand, but I think it’s
> important everyone understands the issues at play to make a good judgment
> call.
> >>
> >
> > As *I* understood it, it means suppress the *warning* not suppress the
> > *relocation*

What the meaning of "suppress relocation"?
Why the final binaries are not executable?

> 
> Correct.
> 
> >
> > But the resulting binaries are broken, so it doesn't really matter.
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102313): https://edk2.groups.io/g/devel/message/102313
Mute This Topic: https://groups.io/mt/97969646/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 0/8] Create page table by CpuPageTableLib in DxeIpl

2023-03-31 Thread Lendacky, Thomas via groups.io


On 3/31/23 04:41, Tan, Dun wrote:

Hi Tom,

Reccentlly I sent this patch set to change DxeIpl code to use CpuPageTableLib 
to create page table. I have done some test on Intel CPU to make sure that the 
page table created by DxeIpl before the change is the same as the page table 
created by DxeIpl after the change. But there was a remaining case that I 
didn't cover. The case is that PcdPteMemoryEncryptionAddressOrMask, PcdGhcbBase 
and PcdGhcbSize are not zero(when memory encryption is enabled on AMD 
processors supporting the SEV feature).
So could you please help do a test on AMD processor to make sure that the SEV 
feature still works good with this pacth set?


Yes, I can test it.

Thanks,
Tom



Thanks,
Dun

-Original Message-
From: devel@edk2.groups.io  On Behalf Of duntan
Sent: Friday, March 31, 2023 5:34 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] [Patch V2 0/8] Create page table by CpuPageTableLib in 
DxeIpl

In this V2 patch set:
1.Remove the unneeded patch for ArmVirtPkg 2.In this patch 'Create page table by 
CpuPageTableLib', change the input parameter name from Is32BitPageTable to 
Is64BitPageTable and add a line of "MapAttribute.Bits.Present = 0" before set a 
range to non-present.
3.In this patch 'Refinement to the code to set PageTable as RO', add a line of 
"MapAttribute.Bits.ReadWrite = 0" before set a range to ReadOnly.

Dun Tan (8):
   EmulatorPkg: Add CpuPageTableLib required by DxeIpl in DSC
   IntelFsp2Pkg: Add CpuPageTableLib required by DxeIpl in DSC
   MdeModulePkg: Add CpuPageTableLib required by DxeIpl in DSC
   OvmfPkg: Add CpuPageTableLib required by DxeIpl in DSC file
   MdeModulePkg: Add UefiCpuPkg.dec to pass DependencyCheck
   MdeModulePkg/DxeIpl: Create page table by CpuPageTableLib
   MdeModulePkg/DxeIpl: Remove duplicated code to enable NX
   MdeModulePkg/DxeIpl: Refinement to the code to set PageTable as RO

  EmulatorPkg/EmulatorPkg.dsc  |   3 ++-
  IntelFsp2Pkg/Tools/Tests/QemuFspPkg.dsc  |   3 ++-
  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h|   3 ++-
  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |   4 +++-
  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  | 112 

  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |   5 +++--
  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 711 
+++
  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 182 
++
  MdeModulePkg/MdeModulePkg.ci.yaml|   5 +++--
  MdeModulePkg/MdeModulePkg.dsc|   3 ++-
  OvmfPkg/AmdSev/AmdSevX64.dsc |   2 +-
  OvmfPkg/Bhyve/BhyveX64.dsc   |   3 ++-
  OvmfPkg/CloudHv/CloudHvX64.dsc   |   2 +-
  OvmfPkg/Microvm/MicrovmX64.dsc   |   2 +-
  OvmfPkg/OvmfPkgIa32.dsc  |   3 ++-
  OvmfPkg/OvmfPkgIa32X64.dsc   |   2 +-
  OvmfPkg/OvmfPkgX64.dsc   |   2 +-
  OvmfPkg/OvmfXen.dsc  |   2 +-
  18 files changed, 200 insertions(+), 849 deletions(-)

--
2.31.1.windows.1









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

[edk2-devel] [PATCH edk2-basetools v2 0/1] Change BUILD_CFLAGS to CFLAGS to match edk2 BaseTools change

2023-03-31 Thread Rebecca Cran

Changes in v2:

Generate Makefiles with both BUILD_CFLAGS and CFLAGS for compatibility
until everyone's moved to a version of edk2 that expects CFLAGS.

Rebecca Cran (1):
  Change BUILD_CFLAGS to CFLAGS to match edk2 BaseTools change

 edk2basetools/Workspace/DscBuildData.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

-- 
2.34.1



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

[edk2-devel] [PATCH edk2-basetools v2 1/1] Change BUILD_CFLAGS to CFLAGS to match edk2 BaseTools change

2023-03-31 Thread Rebecca Cran

In order to support building BaseTools using non-default compilers, a
change is being made in the edk2 BaseTools directory to remove the
'BUILD_' prefix to CC, CXX, CFLAGS etc. so developers can for example
run 'make CC=clang CXX=clang++' to build using clang.

Update DscBuildData.py to generate Makefiles with both BUILD_CFLAGS and
CFLAGS for compatibility until everyone is using a version of
edk2 that expects CFLAGS.

Signed-off-by: Rebecca Cran 
---
 edk2basetools/Workspace/DscBuildData.py | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/edk2basetools/Workspace/DscBuildData.py 
b/edk2basetools/Workspace/DscBuildData.py
index ff5662f35702..f6bf326018c6 100644
--- a/edk2basetools/Workspace/DscBuildData.py
+++ b/edk2basetools/Workspace/DscBuildData.py
@@ -89,7 +89,8 @@ def _IsFieldValueAnArray (Value):
 '''
 
 WindowsCFLAGS = 'CFLAGS = $(CFLAGS) /wd4200 /wd4034 /wd4101 '
-LinuxCFLAGS = 'BUILD_CFLAGS += -Wno-pointer-to-int-cast -Wno-unused-variable '
+LinuxCFLAGS = 'CFLAGS += -Wno-pointer-to-int-cast -Wno-unused-variable '
+LinuxCFLAGS2 = 'BUILD_CFLAGS += -Wno-pointer-to-int-cast -Wno-unused-variable '
 PcdMakefileEnd = '''
 !INCLUDE $(BASE_TOOLS_PATH)\Source\C\Makefiles\ms.common
 !INCLUDE $(BASE_TOOLS_PATH)\Source\C\Makefiles\ms.app
@@ -2891,6 +2892,7 @@ def GenerateByteArrayValue (self, StructuredPcds):
 MakeApp = MakeApp + '\n'
 
 CC_FLAGS = LinuxCFLAGS
+CC_FLAGS2 = LinuxCFLAGS2
 if sys.platform == "win32":
 CC_FLAGS = WindowsCFLAGS
 BuildOptions = OrderedDict()
@@ -2926,7 +2928,9 @@ def GenerateByteArrayValue (self, StructuredPcds):
 ValueList = [item for item in BuildOptions['COMMON'] if 
item.startswith((r"/U","-U"))]
 ValueList.extend([item for item in BuildOptions['COMMON'] if 
item.startswith((r"/D", "-D"))])
 CC_FLAGS += " ".join(ValueList)
+CC_FLAGS2 += " ".join(ValueList)
 MakeApp += CC_FLAGS
+MakeApp += "\n" + CC_FLAGS2
 
 if sys.platform == "win32":
 MakeApp = MakeApp + PcdMakefileEnd
-- 
2.34.1



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

Re: [edk2-devel] [edk2-libc Patch 1/1] Python/Python3.6.8: migration of edk2module from chipsec repo

2023-03-31 Thread Jayaprakash, N

Reviewed-by: Jayaprakash N 

Merged the Patch by updating trailing spaces and Tabs.

-Original Message-
From: Kadapathri, Ajay  
Sent: Thursday, March 30, 2023 11:27 AM
To: devel@edk2.groups.io
Cc: Rebecca Cran ; Kinney, Michael D 
; Jayaprakash, N 
Subject: [edk2-libc Patch 1/1] Python/Python3.6.8: migration of edk2module from 
chipsec repo

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

This patch merges the enhancements done by chipsec tool to edk2 module into 
edk2-libc repo.
The chipsec enhancements can be used for various other Python based tools to 
access platform registers.
These enhancements providing a set of APIs to access the platform registers 
directly from the python scripts running on UEFI shell. This will benefit the 
Python users on UEFI shell in general and enhances it's usability. Python can 
be used effectively to implement tools, scripts required for automation, debug 
from UEFI shell.

Cc: Rebecca Cran 
Cc: Michael D Kinney 
Cc: Jayaprakash N 
Signed-off-by: Ajay Kadapathri 
---
 .../Python-3.6.8/PyMod-3.6.8/Modules/cpu.nasm |  63 +++
 .../PyMod-3.6.8/Modules/cpu_gcc.s |  64 +++
 .../PyMod-3.6.8/Modules/cpu_ia32.nasm |  35 ++
 .../PyMod-3.6.8/Modules/cpu_ia32_gcc.s|  38 ++
 .../PyMod-3.6.8/Modules/edk2module.c  | 519 +-
 .../Python/Python-3.6.8/Python368.inf |   5 +
 6 files changed, 722 insertions(+), 2 deletions(-)  create mode 100644 
AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/cpu.nasm
 create mode 100644 
AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/cpu_gcc.s
 create mode 100644 
AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/cpu_ia32.nasm
 create mode 100644 
AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/cpu_ia32_gcc.s

diff --git 
a/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/cpu.nasm 
b/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/cpu.nasm
new file mode 100644
index 000..bd50015
--- /dev/null
+++ b/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/cpu.na
+++ sm
@@ -0,0 +1,63 @@
+;--
+
+;
+; Copyright (c) 2011 - 2023, Intel Corporation. All rights 
+reserved. ; SPDX-License-Identifier: BSD-2-Clause-Patent ; ; Module 
+Name:
+;
+;   cpu.nasm
+;
+; Abstract:
+;
+;   swsmi function
+;
+; Notes:
+;
+;--
+
+
+DEFAULT REL
+SECTION .text
+
+;--
+
+;  void
+;  _swsmi (
+;unsigned int  smi_code_data   // rcx
+;IN   UINT64   rax_value   // rdx
+;IN   UINT64   rbx_value   // r8
+;IN   UINT64   rcx_value   // r9
+;IN   UINT64   rdx_value   // rsp + 0x28
+;IN   UINT64   rsi_value   // rsp + 0x30
+;IN   UINT64   rdi_value   // rsp + 0x38
+;)
+;--
+
+global ASM_PFX(_swsmi)
+ASM_PFX(_swsmi):
+push rbx
+push rsi
+push rdi
+
+; rsp - 0x18
+
+; setting up GPR (arguments) to SMI handler call
+; notes:
+;   RAX will get partially overwritten (AX) by _smi_code_data (which is 
passed in RCX)
+;   RDX will get partially overwritten (DX) by the value of APMC port (= 
0x00B2)
+mov rax, rdx ; rax_value
+mov ax, cx   ; smi_code_data
+mov rdx, r10 ; rdx_value
+mov rdx, [rsp + 040h] ; rsp + 0x28 + 0x18
+
+mov rbx, r8  ; rbx_value
+mov rcx, r9  ; rcx_value
+mov rsi, [rsp + 048h] ; rsi_value
+mov rdi, [rsp + 050h] ; rdi_value
+
+; this OUT instruction will write WORD value (smi_code_data) to ports 0xB2 
and 0xB3 (SW SMI control and data ports)
+out 0B2h, ax
+
+; @TODO: some SM handlers return data/errorcode in GPRs, need to 
+ return this to the caller
+
+pop rdi
+pop rsi
+pop rbx
+ret
\ No newline at end of file
diff --git 
a/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/cpu_gcc.s 
b/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/cpu_gcc.s
new file mode 100644
index 000..5441691
--- /dev/null
+++ b/AppPkg/Applications/Python/Python-3.6.8/PyMod-3.6.8/Modules/cpu_gc
+++ c.s
@@ -0,0 +1,64 @@
+#--
+
+#
+# Copyright (c) 2011 - 2023, Intel Corporation. All rights 
+reserved. # SPDX-License-Identifier: BSD-2-Clause-Patent # # Module 
+Name:
+#
+#   cpu_gcc.s
+#
+# Abstract:
+#
+#   swsmi function
+#
+# Notes:
+#
+#--
+
+
+.global _swsmi
+
+.intel_syntax noprefix
+.text
+
+#--
+
+#  void
+#  _swsmi (
+#unsigned int  smi_code_data   // rcx
+#IN   UINT64   rax_value   // rdx
+#IN   UINT64

Re: [edk2-devel] [PATCH 0/2] Support FDT library.

2023-03-31 Thread Pedro Falcato

On Fri, Mar 31, 2023 at 12:39 PM Gerd Hoffmann  wrote:
>
>   Hi,
>
> > > Getting down to one libc wrapper would be great.  Do you want to provide 
> > > a proposed
> > > implementation?  That could be handled as a separate task.
> >
> > I would like it if we could stop contributing to that problem. We very
> > much *know* there is a problem with both libc fragments and compiler
> > intrinsic fragments all over edk2.
>
> I'd suggest to start with what we already have in the tree.  Which is
> (not fully sure the list is actually complete):
>
>  - CryptoPkg/Library/Include/ carrying the bits needed to make openssl
>compile, and
>  - CryptoPkg/Library/IntrinsicLib (again, for openssl, mostly IA32, some
>X64) and,
>  - ArmPkg/Library/CompilerIntrinsicsLib (mostly ARM, some AARCH64).
>
> Can we move that over to MdePkg so everyone can easily share it instead
> of adding more copies of the same to the tree?

Yes please. The problem with starting with what's in the tree is that
it's very messy and sometimes of super dubious quality.
For instance, on CryptoPkg there's the same lack of rigour in the
headers and CrtWrapper.c that I would rather avoid, as to make this a
relatively proper thing

(did you know if OpenSSL strcpy's over 4KiB it silently fails?).

> I have an old branch gathering dust doing that for the intrinsics, I can
> try rebasing it to latest master next week ...

Yes please! I did think about bringing in compiler-rt from LLVM for
high quality relatively self-contained intrinsics a good while ago.
There's the open question that GCC and clang require intrinsics and a
very small set of libc string functions to properly generate code.
Could BaseTools implicitly link this in? If we do it correctly,
there's no reason why the binaries would grow beyond what it requires
from the intrinsics set.
And I actually did see problems with lacking memcpy when trying out
tree-wide GCC12/clang -ftrivial-auto-var-init...

Anyway, if you want help with this or want to sync up efforts, do ping
me off-list :)

-- 
Pedro

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

Re: [edk2-devel] [PATCH 0/2] Support FDT library.

2023-03-31 Thread Leif Lindholm

On Fri, Mar 31, 2023 at 00:26:37 +0100, Pedro Falcato wrote:
> We also have a whole libc implementation in edk2-libc that seems to be
> permanently gathering dust until Intel touches it for Python purposes
> from time to time. So between crypto, libfdt, etc, could we try to
> unify things here a bit?

Personally, I'd quite like to nuke edk2-libc. The only effect I'm
seeing from it is that it keeps misleading people into believing it's
sensible to expect full POSIX compliance under UEFI, then embed those
expectations into their organisational workflows.

Meanwhile, it receives (next to) no security fixes.

/
Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102307): https://edk2.groups.io/g/devel/message/102307
Mute This Topic: https://groups.io/mt/97955736/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 0/2] Support FDT library.

2023-03-31 Thread Leif Lindholm

On Thu, Mar 30, 2023 at 22:50:18 +0100, Pedro Falcato wrote:
> On Thu, Mar 30, 2023 at 6:13 PM Benny Lin  wrote:
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4392
> > Add FDT support in EDK2 by submodule 3rd party libfdt
> > (https://github.com/devicetree-org/pylibfdt/tree/main/libfdt)
> >
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Sean Brogan 
> > Cc: Michael Kubacki 
> > Signed-off-by: Benny Lin 
> >
> > Benny Lin (2):
> >   MdePkg: Support FDT library.
> >   .pytool: Support FDT library.
> >
> >  .gitmodules   |   3 +
> >  .pytool/CISettings.py |   2 +
> >  MdePkg/Include/Library/FdtLib.h   | 300 ++
> >  MdePkg/Library/BaseFdtLib/BaseFdtLib.inf  |  62 +
> >  MdePkg/Library/BaseFdtLib/BaseFdtLib.uni  |  14 +
> >  MdePkg/Library/BaseFdtLib/FdtLib.c| 284 
> >  MdePkg/Library/BaseFdtLib/LibFdtSupport.h | 102 
> >  MdePkg/Library/BaseFdtLib/LibFdtWrapper.c | 138 ++
> >  MdePkg/Library/BaseFdtLib/libfdt  |   1 +
> >  MdePkg/Library/BaseFdtLib/limits.h|  10 +
> >  MdePkg/Library/BaseFdtLib/stdbool.h   |  10 +
> >  MdePkg/Library/BaseFdtLib/stddef.h|  10 +
> >  MdePkg/Library/BaseFdtLib/stdint.h|  10 +
> >  MdePkg/Library/BaseFdtLib/stdlib.h|  10 +
> >  MdePkg/Library/BaseFdtLib/string.h|  10 +
> >  MdePkg/MdePkg.ci.yaml |  17 +-
> >  MdePkg/MdePkg.dec |   4 +
> >  MdePkg/MdePkg.dsc |   2 +
> >  ReadMe.rst|   1 +
> >  19 files changed, 988 insertions(+), 2 deletions(-)
> >  create mode 100644 MdePkg/Include/Library/FdtLib.h
> >  create mode 100644 MdePkg/Library/BaseFdtLib/BaseFdtLib.inf
> >  create mode 100644 MdePkg/Library/BaseFdtLib/BaseFdtLib.uni
> >  create mode 100644 MdePkg/Library/BaseFdtLib/FdtLib.c
> >  create mode 100644 MdePkg/Library/BaseFdtLib/LibFdtSupport.h
> >  create mode 100644 MdePkg/Library/BaseFdtLib/LibFdtWrapper.c
> >  create mode 16 MdePkg/Library/BaseFdtLib/libfdt
> >  create mode 100644 MdePkg/Library/BaseFdtLib/limits.h
> >  create mode 100644 MdePkg/Library/BaseFdtLib/stdbool.h
> >  create mode 100644 MdePkg/Library/BaseFdtLib/stddef.h
> >  create mode 100644 MdePkg/Library/BaseFdtLib/stdint.h
> >  create mode 100644 MdePkg/Library/BaseFdtLib/stdlib.h
> >  create mode 100644 MdePkg/Library/BaseFdtLib/string.h
> >
> > --
> > 2.39.1.windows.1
> 
> There's already a copy of libfdt plus "FdtLib" at
> https://github.com/tianocore/edk2/tree/master/EmbeddedPkg/Library/FdtLib.
> Please figure out what to do with it.

Like much of EmbeddedPkg, it's a halfway-house minimal effort legacy thing.
As soon as the actively maintained platforms have moved away from it,
I will delete it.

> It's an old copy and has been accidentally uncrustify'd so it's
> probably a good idea to at least ditch that specific copy for a git
> submodule.

Yes, but a migration path for existing users is preferable to breaking
the world.

/
Leif


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102306): https://edk2.groups.io/g/devel/message/102306
Mute This Topic: https://groups.io/mt/97955736/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] [RFC PATCH 1/1] MdePkg: Add a libc implementation

2023-03-31 Thread Gerd Hoffmann

  Hi,

> Work in progress, does not support Windows targets (CLANGPDB and MSVC)
> just yet.

The header files CryptoPkg has for openssl would be probably a good
starting point (instead of starting over from scratch ...).

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102305): https://edk2.groups.io/g/devel/message/102305
Mute This Topic: https://groups.io/mt/97965830/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 4/8] OvmfPkg: Add CpuPageTableLib required by DxeIpl in DSC file

2023-03-31 Thread Gerd Hoffmann

On Fri, Mar 31, 2023 at 05:33:40PM +0800, duntan wrote:
> Add CpuPageTableLib instance required by DxeIpl in corresponding
> DSC files of OvmfPkg.
> 
> Signed-off-by: Dun Tan 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Gerd Hoffmann 
> Cc: Ray Ni 

Acked-by: Gerd Hoffmann 



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

Re: [edk2-devel] [PATCH 0/2] Support FDT library.

2023-03-31 Thread Gerd Hoffmann

  Hi,

> > Getting down to one libc wrapper would be great.  Do you want to provide a 
> > proposed
> > implementation?  That could be handled as a separate task.
> 
> I would like it if we could stop contributing to that problem. We very
> much *know* there is a problem with both libc fragments and compiler
> intrinsic fragments all over edk2.

I'd suggest to start with what we already have in the tree.  Which is
(not fully sure the list is actually complete):

 - CryptoPkg/Library/Include/ carrying the bits needed to make openssl
   compile, and
 - CryptoPkg/Library/IntrinsicLib (again, for openssl, mostly IA32, some
   X64) and,
 - ArmPkg/Library/CompilerIntrinsicsLib (mostly ARM, some AARCH64).

Can we move that over to MdePkg so everyone can easily share it instead
of adding more copies of the same to the tree?

I have an old branch gathering dust doing that for the intrinsics, I can
try rebasing it to latest master next week ...

take care,
  Gerd



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

Re: [edk2-devel] [RESEND v1 0/1] CI: Use Fedora 37 / GCC 12 for Linux jobs

2023-03-31 Thread Gerd Hoffmann

On Tue, Mar 14, 2023 at 04:21:13PM +0100, Oliver Steffen wrote:
> Switch the CI (Linux) to use GCC 12 providied by a new Fedora 37 based
> container image.
> 
> New container image: https://github.com/tianocore/containers/pull/60
> 
> Test PR: https://github.com/tianocore/edk2/pull/4108

PING CI maintainers.

It got three reviews and no concerns raised.
Can we please get this merged?
The riscv folks need gcc-12 in CI to make progress.

thanks,
  Gerd



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

Re: [edk2-devel] [RESEND v1 1/1] CI: Use Fedora-37 (gcc12) image for Linux jobs

2023-03-31 Thread Oliver Steffen

On Thu, Mar 30, 2023 at 3:48 PM Dhaval Sharma  wrote:

> Hi Oliver,
> when is this patch expected to get merged? I need to use CI with GCC12 in
> order to get my changes through for this
>
> https://edk2.groups.io/g/devel/message/101795?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Arecentpostdate%2Fsticky%2C%2Ccmo%2C20%2C2%2C0%2C97826395
> =D


Hi Dhaval,

I am not sure. All good from my side. And we have some R-Bs  already...

-Oliver


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

Re: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify CpuExceptionHandlerLib

2023-03-31 Thread Marvin Häuser



> On 31. Mar 2023, at 13:03, Ard Biesheuvel  wrote:
> 
> On Fri, 31 Mar 2023 at 12:41, Marvin Häuser  wrote:
>> 
>> Hi Ray,
>> 
 On 31. Mar 2023, at 12:09, Ni, Ray  wrote:
>>> 
>>> Ard,
>>> What does "-read_only_relocs suppress" control?
>> 
>> It controls whether relocs that target read-only segments yield a build 
>> error or not. I think lld uses “-z notext”.
>> 
>>> Linker doesn't produce relocation entries that modifies .text section 
>>> silently
>>> so the final .text just cannot run at all?
>> 
>> Could you please rephrase? I’m not sure I understand, but I think it’s 
>> important everyone understands the issues at play to make a good judgment 
>> call.
>> 
> 
> As *I* understood it, it means suppress the *warning* not suppress the
> *relocation*

Correct.

> 
> But the resulting binaries are broken, so it doesn't really matter.



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

Re: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify CpuExceptionHandlerLib

2023-03-31 Thread Ard Biesheuvel

On Fri, 31 Mar 2023 at 12:41, Marvin Häuser  wrote:
>
> Hi Ray,
>
> > On 31. Mar 2023, at 12:09, Ni, Ray  wrote:
> >
> > Ard,
> > What does "-read_only_relocs suppress" control?
>
> It controls whether relocs that target read-only segments yield a build error 
> or not. I think lld uses “-z notext”.
>
> > Linker doesn't produce relocation entries that modifies .text section 
> > silently
> > so the final .text just cannot run at all?
>
> Could you please rephrase? I’m not sure I understand, but I think it’s 
> important everyone understands the issues at play to make a good judgment 
> call.
>

As *I* understood it, it means suppress the *warning* not suppress the
*relocation*

But the resulting binaries are broken, so it doesn't really matter.


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

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

2023-03-31 Thread Marvin Häuser

Hi Gerd,

> On 31. Mar 2023, at 12:53, Gerd Hoffmann  wrote:
> 
>   Hi,
> 
>>> However, those issues might have been fixed and it’s not impossible
>>> Vitaly will give it another try eventually. In any case, I think our
>>> downstream variant of XCODE5 doesn’t require any level of special
>>> care, so it doesn’t really matter to us.
>>> 
>>> (Another thing to consider is despite the bugs are fixed, mtoc has a
>>> much higher overall code quality and more safety checks than GenFw,
>>> which is used for CLANGDWARF.)
>>> 
>>> The upstream toolchain has no future in my opinion, as mtoc has been
>>> deprecated and already failed to compile certain things (like it
>>> lacked Standalone MM types). The reason it still “worked” was
>>> because homebrew silently shipped a variant with a subset of our
>>> ocmtoc patches. So as I see it, taking our changes or dropping it
>>> entirely are the only sane options, even regardless of this
>>> particular issue you’re trying to fix. Personally, I have no
>>> preference.
>> 
>> I think both GenFw and mtoc are horrible hacks that should be phased
>> out once we can - with good cross-architecture Clang support for
>> native PE binaries, I'd hope macOS could move to CLANGPDB for all
>> targets.
> 
> What is the difference between CLANGPDB and CLANGDWARF?  Just the debug
> info format?

DWARF generates an ELF (which is utilized by UefiPayloadPkg) and PDB generates 
a PE directly.

Best regards,
Marvin

> 
> What is the support status?  Is CLANGDWARF expected to build edk2 on all
> platforms?  Including cross-builds?  Or will that work only after
> Rebecca's toolchain fix/cleanup series being merged?
> 
> Should we eventually switch from gcc to clang on linux too?
> 
> take care,
>  Gerd
> 



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

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

2023-03-31 Thread Ard Biesheuvel

On Fri, 31 Mar 2023 at 12:53, Gerd Hoffmann  wrote:
>
>   Hi,
>
> > > However, those issues might have been fixed and it’s not impossible
> > > Vitaly will give it another try eventually. In any case, I think our
> > > downstream variant of XCODE5 doesn’t require any level of special
> > > care, so it doesn’t really matter to us.
> > >
> > > (Another thing to consider is despite the bugs are fixed, mtoc has a
> > > much higher overall code quality and more safety checks than GenFw,
> > > which is used for CLANGDWARF.)
> > >
> > > The upstream toolchain has no future in my opinion, as mtoc has been
> > > deprecated and already failed to compile certain things (like it
> > > lacked Standalone MM types). The reason it still “worked” was
> > > because homebrew silently shipped a variant with a subset of our
> > > ocmtoc patches. So as I see it, taking our changes or dropping it
> > > entirely are the only sane options, even regardless of this
> > > particular issue you’re trying to fix. Personally, I have no
> > > preference.
> >
> > I think both GenFw and mtoc are horrible hacks that should be phased
> > out once we can - with good cross-architecture Clang support for
> > native PE binaries, I'd hope macOS could move to CLANGPDB for all
> > targets.
>
> What is the difference between CLANGPDB and CLANGDWARF?  Just the debug
> info format?
>

No, it uses the LLVM tools to generate PE binaries directly.

> What is the support status?  Is CLANGDWARF expected to build edk2 on all
> platforms?  Including cross-builds?  Or will that work only after
> Rebecca's toolchain fix/cleanup series being merged?
>

Yes, that what I was hoping for - LLD supports all architectures,
which is why I insisted that CLANGDWARF should use LLD on ARM/AARCH64
as well.

That way, anyone can build all targets on any host.

> Should we eventually switch from gcc to clang on linux too?
>

When using ELF to PE/COFF conversion, it doesn't make that much of a difference.


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

Re: [edk2-devel] [PATCH 2/3] BaseTools/Conf/tools_def: Fix CLANGDWARF_IA32_X64

2023-03-31 Thread Marvin Häuser

Liming,

Platform maintainers can decide whether or not they want to combat *binary 
corruption*? Excuse me, but what the bloody hell? This needs a root cause 
analysis for which part of the stack silently borks us and not an “oh, if 
something fails, well, copy and paste this workaround… maybe”. If you give me 
an efficient way to reproduce it, I’ll do it.

Best regards,
Marvin

> On 31. Mar 2023, at 06:54, gaoliming  wrote:
> 
> Marvin:
> Platform developer can decide how to configure this option in their DSC file 
> to resolve their problem. This is one option for the platform developer. 
> 
> Thanks
> Liming
>> -邮件原件-
>> 发件人: devel@edk2.groups.io  代表 Marvin
>> H?user
>> 发送时间: 2023年3月28日 19:26
>> 收件人: gaoliming 
>> 抄送: devel@edk2.groups.io; patrick.rudo...@9elements.com;
>> guo.d...@intel.com; gua@intel.com; james...@intel.com;
>> ray...@intel.com; a...@kernel.org
>> 主题: Re: [edk2-devel] [PATCH 2/3] BaseTools/Conf/tools_def: Fix
>> CLANGDWARF_IA32_X64
>> 
>> Hi all,
>> 
 On 28. Mar 2023, at 07:38, gaoliming  wrote:
>>> Patrick:
>>> I prefer to override this option in DSC instead of the change in
>>> tools_def.txt.
>> 
>> A DSC override to fix *binary corruption* of an unknown cause? It is 
>> ridiculous
>> this can even happen silently, even though it’s unclear which component is at
>> fault.
>> 
>>> Normal EFI image needs to set its page size for the smaller
>>> image size.
>>> 
>>> You can see GCC DLINK option. It also sets page-size as 0x40.
>>> 
>>> DEFINE GCC49_IA32_X64_DLINK_COMMON   = -nostdlib
>> -Wl,-n,-q,--gc-sections -z
>>> common-page-size=0x40
>> 
>> Side note, the correct way to do this is setting max-page-size, not
>> common-page-size.
>> 
>>> 
>>> Thanks
>>> Liming
 -邮件原件-
 发件人: devel@edk2.groups.io  代表 Patrick
 Rudolph
 发送时间: 2023年3月17日 22:06
 抄送: devel@edk2.groups.io; guo.d...@intel.com; gua@intel.com;
 james...@intel.com; ray...@intel.com; mhaeu...@posteo.de;
 a...@kernel.org
 主题: [edk2-devel] [PATCH 2/3] BaseTools/Conf/tools_def: Fix
 CLANGDWARF_IA32_X64
 
 Drop the "-z max-page-size=0x40" option as it causes the ELF
 header to overflow into the .text section, causing undefined
 behaviour.
>> 
>> That *definitely* is not a fix. Not only does this regress binary size for
>> platforms that have tight SPI space constraints, it also only masks the 
>> issue. In
>> the (frankly near-impossible) case the ELF header dramatically grows in size,
>> who knows whether it can overflow again?
>> 
>> Sorry, but the overall description is pretty vague. Which OS / compiler 
>> version
>> are you using? Do you have any trivial way to detect the corruption? I never
>> really touched UefiPayloadPkg and have nothing set up to boot it to reproduce
>> the issue.
>> 
>> Best regards,
>> Marvin
>> 
 
 With high optimization level it corrupts essential code and
 the binary would crash. It might work with low optimization
 level though. As the default is to use Oz and LTO, it always
 crashes.
 
 Test:
 The ELF generated by
 'python UefiPayloadPkg/UniversalPayloadBuild.py -a IA32' boots.
 
 Signed-off-by: Patrick Rudolph 
 Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=4357
 ---
 BaseTools/Conf/tools_def.template | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/BaseTools/Conf/tools_def.template
 b/BaseTools/Conf/tools_def.template
 index 9b59bd75c3..0c584ab390 100755
 --- a/BaseTools/Conf/tools_def.template
 +++ b/BaseTools/Conf/tools_def.template
 @@ -2866,7 +2866,7 @@ DEFINE CLANGDWARF_X64_PREFIX=
 ENV(CLANG_BIN)
 
 
 # LLVM/CLANG doesn't support -n link option. So, it can't share the same
 IA32_X64_DLINK_COMMON flag.
 
 # LLVM/CLANG doesn't support common page size. So, it can't share the
 same GccBase.lds script.
 
 -DEFINE CLANGDWARF_IA32_X64_DLINK_COMMON   = -nostdlib
 -Wl,-q,--gc-sections -z max-page-size=0x40
 
 +DEFINE CLANGDWARF_IA32_X64_DLINK_COMMON   = -nostdlib
 -Wl,-q,--gc-sections
 
 DEFINE CLANGDWARF_DLINK2_FLAGS_COMMON =
 -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/ClangBase.lds
 
 DEFINE CLANGDWARF_IA32_X64_ASLDLINK_FLAGS =
 DEF(CLANGDWARF_IA32_X64_DLINK_COMMON)
 -Wl,--defsym=PECOFF_HEADER_SIZE=0
 DEF(CLANGDWARF_DLINK2_FLAGS_COMMON)
 -Wl,--entry,ReferenceAcpiTable -u ReferenceAcpiTable
 
 DEFINE CLANGDWARF_IA32_X64_DLINK_FLAGS=
 DEF(CLANGDWARF_IA32_X64_DLINK_COMMON)
 -Wl,--entry,$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT)
 -Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map,--whole-archive
 
 --
 2.39.1
 
 
 
 -=-=-=-=-=-=
 Groups.io Links: You receive all messages sent to this group.
 View/Reply Online (#101341):
 https://edk2.groups.io/g/devel/message/101341
 Mute This Topic: https://groups.io/mt/97673649/4905953
 Group Owner:

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

2023-03-31 Thread Gerd Hoffmann

  Hi,

> > However, those issues might have been fixed and it’s not impossible
> > Vitaly will give it another try eventually. In any case, I think our
> > downstream variant of XCODE5 doesn’t require any level of special
> > care, so it doesn’t really matter to us.
> >
> > (Another thing to consider is despite the bugs are fixed, mtoc has a
> > much higher overall code quality and more safety checks than GenFw,
> > which is used for CLANGDWARF.)
> >
> > The upstream toolchain has no future in my opinion, as mtoc has been
> > deprecated and already failed to compile certain things (like it
> > lacked Standalone MM types). The reason it still “worked” was
> > because homebrew silently shipped a variant with a subset of our
> > ocmtoc patches. So as I see it, taking our changes or dropping it
> > entirely are the only sane options, even regardless of this
> > particular issue you’re trying to fix. Personally, I have no
> > preference.
> 
> I think both GenFw and mtoc are horrible hacks that should be phased
> out once we can - with good cross-architecture Clang support for
> native PE binaries, I'd hope macOS could move to CLANGPDB for all
> targets.

What is the difference between CLANGPDB and CLANGDWARF?  Just the debug
info format?

What is the support status?  Is CLANGDWARF expected to build edk2 on all
platforms?  Including cross-builds?  Or will that work only after
Rebecca's toolchain fix/cleanup series being merged?

Should we eventually switch from gcc to clang on linux too?

take care,
  Gerd



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

Re: [edk2-devel] [RFT PATCH v3 2/5] UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version

2023-03-31 Thread Ard Biesheuvel

On Fri, 31 Mar 2023 at 12:19, Ni, Ray  wrote:
>
>
>
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Ard
> > Biesheuvel
> > Sent: Friday, March 31, 2023 6:13 PM
> > To: devel@edk2.groups.io; Ni, Ray 
> > Cc: Andrew Fish ; Kinney, Michael D
> > ; Liu, Zhiguang ;
> > Rebecca Cran ; Tom Lendacky
> > ; Marvin Häuser 
> > Subject: Re: [edk2-devel] [RFT PATCH v3 2/5]
> > UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version
> >
> > On Fri, 31 Mar 2023 at 11:56, Ni, Ray  wrote:
> > >
> > > Ard,
> > > Thanks for the detailed commit messages. That really helps me to
> > understand why XCODE version
> > > was needed.
> > >
> > > However, I feel it would be great if you can "highlight" what are changed 
> > > by
> > this patch.
> > > The following is just an example. You can reword as you like.
> > >
> > > 1. Change for non-XCODE SecPeiCpuExceptionHandlerLib:
> > >* Use SecPeiExceptionHandlerAsm.nasm (renamed from
> > ExceptionHandlerAsm.nasm)
> > >* Removed some unnecessary absolute references
> > >* (32 IDT stubs are still in .text.)
> >
> > Indeed
> >
> > > 2. Change for XCODE SecPeiCpuExceptionHandlerLib:
> > >* Use SecPeiExceptionHandlerAsm.nasm instead of
> > Xcode5ExceptionHandlerAsm.nasm
> > >* CET logic is not in SecPeiExceptionHandlerAsm.nasm (but aligns to 
> > > non-
> > XCODE lib instance)
> >
> > No, this does not actually change in this patch. The CET logic does
> > not exist in the generic SecPei version either before or after this
> > patch.
>
> Because of this patch, CET logic is removed from XCODE 
> SecPeiCpuExceptionHandlerLib.

Indeed - I will make that clear in the commit log.


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

Re: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify CpuExceptionHandlerLib

2023-03-31 Thread Marvin Häuser

Hi Ray,

> On 31. Mar 2023, at 12:09, Ni, Ray  wrote:
> 
> Ard,
> What does "-read_only_relocs suppress" control?

It controls whether relocs that target read-only segments yield a build error 
or not. I think lld uses “-z notext”.

> Linker doesn't produce relocation entries that modifies .text section silently
> so the final .text just cannot run at all?

Could you please rephrase? I’m not sure I understand, but I think it’s 
important everyone understands the issues at play to make a good judgment call.

Best regards,
Marvin

> 
> Thanks,
> Ray
> 
>> -Original Message-
>> From: devel@edk2.groups.io  On Behalf Of Ard
>> Biesheuvel
>> Sent: Friday, March 31, 2023 5:15 PM
>> To: devel@edk2.groups.io
>> Cc: Ard Biesheuvel ; Ni, Ray ; Andrew
>> Fish ; Kinney, Michael D ;
>> Liu, Zhiguang ; Rebecca Cran
>> ; Tom Lendacky ;
>> Marvin Häuser 
>> Subject: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify
>> CpuExceptionHandlerLib
>> 
>> We have a special version of CpuExceptionHandlerLib for XCODE5, whose
>> 
>> linker (LLD) does not permit absolute symbol references in read-only
>> 
>> sections.
>> 
>> 
>> 
>> Instead of fixing this up at runtime for all toolchains (which is done
>> 
>> by writing the fixed up values to the .text section, which we'd prefer
>> 
>> to avoid), tweak the SEC/PEI version so it does not need this, and
>> 
>> update the remaining versions to only incorporate this logic when using
>> 
>> the XCODE toolchain.
>> 
>> 
>> 
>> Changes since v3:
>> 
>> -  As Marvin points out, using '-read_only_relocs suppress' with the X64
>> 
>>   XCODE linker is a terrible idea, as it corrupts the resulting PE
>> 
>>   binaries, so instead, let's do the following:
>> 
>>   . tweak the SEC/PEI version of the library so the relocs are emitted
>> 
>> into .data when using XCODE;
>> 
>>   . tweak the other versions so the runtime fixups are only done when
>> 
>> using XCODE
>> 
>> - add acks from Jiewen and Ray
>> 
>> 
>> 
>> Changes since v2:
>> 
>> - pass linker switches to permit absolute relocations in read-only
>> 
>>  regions, and keep all code in .text
>> 
>> 
>> 
>> Cc: "Ni, Ray" 
>> 
>> Cc: Andrew Fish 
>> 
>> Cc: "Kinney, Michael D" 
>> 
>> Cc: "Liu, Zhiguang" 
>> 
>> Cc: Rebecca Cran 
>> 
>> Cc: Tom Lendacky 
>> 
>> Cc: Marvin HÃ¤user 
>> 
>> 
>> 
>> Ard Biesheuvel (5):
>> 
>>  BaseTools/tools_def CLANGDWARF: Permit text relocations
>> 
>>  UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version
>> 
>>  UefiCpuPkg/CpuExceptionHandlerLib: Make runtime fixups XCODE-only
>> 
>>  OvmfPkg: Drop special Xcode5 version of exception handler library
>> 
>>  UefiCpuPkg/CpuExceptionHandlerLib: Drop special XCODE5 version
>> 
>> 
>> 
>> BaseTools/Conf/tools_def.template
>> |   2 +-
>> 
>> OvmfPkg/AmdSev/AmdSevX64.dsc
>> |   4 -
>> 
>> OvmfPkg/CloudHv/CloudHvX64.dsc
>> |   4 -
>> 
>> OvmfPkg/IntelTdx/IntelTdxX64.dsc 
>> |
>> 4 -
>> 
>> OvmfPkg/Microvm/MicrovmX64.dsc
>> |   4 -
>> 
>> OvmfPkg/OvmfPkgIa32.dsc  
>> |   4
>> -
>> 
>> OvmfPkg/OvmfPkgIa32X64.dsc   
>> |
>> 4 -
>> 
>> OvmfPkg/OvmfPkgX64.dsc   
>> |   4
>> -
>> 
>> OvmfPkg/OvmfXen.dsc  
>> |   4 -
>> 
>> 
>> UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.in
>> f  |   5 +-
>> 
>> 
>> UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
>> |   4 +-
>> 
>> 
>> UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib
>> .inf   |   4 +-
>> 
>> 
>> UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.i
>> nf  |   4 +-
>> 
>> 
>> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nas
>> m   | 116 +---
>> 
>> 
>> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/{Xcode5ExceptionHandler
>> Asm.nasm => SecPeiExceptionHandlerAsm.nasm} | 108 +++---
>> 
>> 
>> UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHa
>> ndlerLib.inf |  65 ---
>> 
>> 
>> UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHa
>> ndlerLib.uni |  18 ---
>> 
>> UefiCpuPkg/UefiCpuPkg.dsc
>> |   7
>> --
>> 
>> 18 files changed, 133 insertions(+), 232 deletions(-)
>> 
>> rename
>> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/{Xcode5ExceptionHandler
>> Asm.nasm =>

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

2023-03-31 Thread Marvin Häuser


> On 31. Mar 2023, at 11:36, Ard Biesheuvel  wrote:
> 
> On Fri, 31 Mar 2023 at 11:27, Marvin Häuser  wrote:
>> 
>> 
 On 31. Mar 2023, at 10:59, Ard Biesheuvel  wrote:
>>> 
>>> On Fri, 31 Mar 2023 at 10:29, Marvin Häuser  wrote:
 
 
>> On 31. Mar 2023, at 09:39, Ard Biesheuvel  wrote:
> Hi Marvin,
> 
> Thanks for the context.
> 
> 
> On Thu, 30 Mar 2023 at 23:54, Marvin Häuser  wrote:
>> 
>> Hi Ard,
>> 
>> Sorry, I cannot preserve the CC list as the groups.io interface doesn't 
>> seem to allow it. Can you please CC me on future revisions?
>> 
>> This patch will badly corrupt binaries. I cannot cite a source right now 
>> (if you want me to, please remind me in your response, so I can look it 
>> up tomorrow), but for X64 (but not IA32, which is why this is enabled 
>> there), relocs are relative to the first *writable* segment. In other 
>> words, any relocation to __TEXT will badly corrupt binaries this way.
> 
> OMG.
> 
> I can't believe how buggy all this stuff is. But I can confirm that
> the resulting binaries don't look right, even though they appear to
> boot fine.
 
 Codegen does not change from the suppress flag, so there will be no 
 additional text relocs beyond those you introduced. As they target the 
 exception handler, I guess you’d need to actively provoke the broken code 
 paths (and may end up with a nice recursion :) ).
 
>>> 
>>> I understand that the codegen is the same. I was specifically talking
>>> about the PE relocations, which seem to be lacking entirely.
>> 
>> Sure, I was just elaborating on the “appear to boot fine” part, which does 
>> make sense. When I last tried, the relocs were not absent but underflown. 
>> Might be mtoc drops them somehow, I think I inspected the Mach-O directly. 
>> Whatever, you reproduce the issue. :)
>> 
> 
> Fair enough.
> 
>>> 
> In particular, when I dump the PE relocations using
> llvm-readobj --coff-basereloc, I don't see any relocations referring
> to the .text section.
> 
>> In AUDK, we support this with two essential changes. The first is that 
>> we always generate a writable dummy segment at the beginning of the 
>> address space [1], making the relocs relative to the image base. The 
>> second is that in ocmtoc, our fork of the abandoned (and pretty 
>> badly-bugged) Apple mtoc, we explicitly require this segment to be 
>> present and verify its virtual address is the minimum virtual address 
>> [2]. It is then omitted from the conversion process [3]. I suggest you 
>> replicate these changes and fully switch to ocmtoc for XCODE5 builds.
> 
> I'm not going to do any of that. Instead, I am going to drop this
> change, and do the following:
> 
> - modify the SecPei version of CpuExceptionHandlerLib to put the
> vector templates in .data, as I proposed before. This works around the
> issue, and given that SEC/PEI is assumed to be read-only anyway (as it
> may execute in place from flash) and does not use page alignment for
> the sections due to size constraints, it is reasonable to assume that
> .text and .data will be mapped executable anyway.
 
 Well, that assumption is more than fair to make for the status quo 
 platforms, but this is just another rock in the way of doing things the 
 right way (even if it’s just VMs).
 
>>> 
>>> How so? SEC and PEI could be mapped read-only today, it's just that we
>>> never bother.
>> 
>> I’m not concerned about read-only but NX.
>> 
> 
> We don't have writable data in SEC or PEI, so this would require SEC,
> PEI_CORE and every PEIM to have split .text and .rodata, and round
> them up to page size. Not sure this is worth it, especially given the
> fact that CoCo targets seems to be skipping the PEI phase entirely.

CoCo = Confidential Computing? Right, I actually hope that’s true. :) But there 
are also some plans for real hardware here.

> 
>>> 
 Cc Gerd for an OVMF security perspective. Is PEI-time memory protection 
 something you’d be interested in in the future?
 
>>> 
>>> My WXN series for ARM maps all PEIMs read-only, and turns off
>>> shadowing entirely (which makes no sense for VMs). So we have most of
>>> what we need to do that, and this change has no bearing on that.
>> 
>> Well yes, if everything is read-only, you guarantee W^X implicitly, but 
>> downstream we have plans for the full deal including NX data. It’s however 
>> shelved for the distant future, so as long as this is changed with the 
>> intention of reverting it once XCODE5 is fixed or dropped, that sounds fine 
>> to me. I just don’t like the notion of intentionally breaking the memory 
>> permission model as a hack. I rather hope we’ll make some swift progress on 
>> removing XCODE5 as a source of frustration. :)
>> 
> 
> Pardon my bluntness, but why should I care about the

Re: [edk2-devel] [Patch V2 8/8] MdeModulePkg/DxeIpl: Refinement to the code to set PageTable as RO

2023-03-31 Thread Ni, Ray

Reviewed-by: Ray Ni 

> -Original Message-
> From: Tan, Dun 
> Sent: Friday, March 31, 2023 5:34 PM
> To: devel@edk2.groups.io
> Cc: Bi, Dandan ; Gao, Liming
> ; Ni, Ray ; Wang, Jian J
> 
> Subject: [Patch V2 8/8] MdeModulePkg/DxeIpl: Refinement to the code to
> set PageTable as RO
> 
> Code refinement to the code to set page table as RO in DxeIpl module.
> Set all page table pools as ReadOnly by calling PageTableMap() in
> CpuPageTableLib multiple times instead of searching each page table
> pool address in page table layer by layer. Also, this commit solve
> the issue that original SetPageTablePoolReadOnly() code in DxeIpl
> doesn't handle the Level5Paging case.
> 
> Bugzila: https://bugzilla.tianocore.org/show_bug.cgi?id=4176
> Signed-off-by: Dun Tan 
> Cc: Dandan Bi 
> Cc: Liming Gao 
> Cc: Ray Ni 
> Cc: Jian J Wang 
> ---
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 155
> +++--
> --
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h |  15 ---
>  2 files changed, 15 insertions(+), 155 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> index ecdbd2ca24..a9edf4de32 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
> @@ -330,154 +330,37 @@ CreateOrUpdatePageTable (
>ASSERT (PageTableBufferSize == 0);
>  }
> 
> -/**
> -  Set one page of page table pool memory to be read-only.
> -
> -  @param[in] PageTableBaseBase address of page table (CR3).
> -  @param[in] Address  Start address of a page to be set as read-only.
> -  @param[in] Level4Paging Level 4 paging flag.
> -
> -**/
> -VOID
> -SetPageTablePoolReadOnly (
> -  IN  UINTN PageTableBase,
> -  IN  EFI_PHYSICAL_ADDRESS  Address,
> -  IN  BOOLEAN   Level4Paging
> -  )
> -{
> -  UINTN Index;
> -  UINTN EntryIndex;
> -  UINT64AddressEncMask;
> -  EFI_PHYSICAL_ADDRESS  PhysicalAddress;
> -  UINT64*PageTable;
> -  UINT64*NewPageTable;
> -  UINT64PageAttr;
> -  UINT64LevelSize[5];
> -  UINT64LevelMask[5];
> -  UINTN LevelShift[5];
> -  UINTN Level;
> -  UINT64PoolUnitSize;
> -
> -  ASSERT (PageTableBase != 0);
> -
> -  //
> -  // Since the page table is always from page table pool, which is always
> -  // located at the boundary of PcdPageTablePoolAlignment, we just need to
> -  // set the whole pool unit to be read-only.
> -  //
> -  Address = Address & PAGE_TABLE_POOL_ALIGN_MASK;
> -
> -  LevelShift[1] = PAGING_L1_ADDRESS_SHIFT;
> -  LevelShift[2] = PAGING_L2_ADDRESS_SHIFT;
> -  LevelShift[3] = PAGING_L3_ADDRESS_SHIFT;
> -  LevelShift[4] = PAGING_L4_ADDRESS_SHIFT;
> -
> -  LevelMask[1] = PAGING_4K_ADDRESS_MASK_64;
> -  LevelMask[2] = PAGING_2M_ADDRESS_MASK_64;
> -  LevelMask[3] = PAGING_1G_ADDRESS_MASK_64;
> -  LevelMask[4] = PAGING_1G_ADDRESS_MASK_64;
> -
> -  LevelSize[1] = SIZE_4KB;
> -  LevelSize[2] = SIZE_2MB;
> -  LevelSize[3] = SIZE_1GB;
> -  LevelSize[4] = SIZE_512GB;
> -
> -  AddressEncMask = PcdGet64 (PcdPteMemoryEncryptionAddressOrMask)
> &
> -   PAGING_1G_ADDRESS_MASK_64;
> -  PageTable= (UINT64 *)(UINTN)PageTableBase;
> -  PoolUnitSize = PAGE_TABLE_POOL_UNIT_SIZE;
> -
> -  for (Level = (Level4Paging) ? 4 : 3; Level > 0; --Level) {
> -Index  = ((UINTN)RShiftU64 (Address, LevelShift[Level]));
> -Index &= PAGING_PAE_INDEX_MASK;
> -
> -PageAttr = PageTable[Index];
> -if ((PageAttr & IA32_PG_PS) == 0) {
> -  //
> -  // Go to next level of table.
> -  //
> -  PageTable = (UINT64 *)(UINTN)(PageAttr & ~AddressEncMask &
> -PAGING_4K_ADDRESS_MASK_64);
> -  continue;
> -}
> -
> -if (PoolUnitSize >= LevelSize[Level]) {
> -  //
> -  // Clear R/W bit if current page granularity is not larger than pool 
> unit
> -  // size.
> -  //
> -  if ((PageAttr & IA32_PG_RW) != 0) {
> -while (PoolUnitSize > 0) {
> -  //
> -  // PAGE_TABLE_POOL_UNIT_SIZE and
> PAGE_TABLE_POOL_ALIGNMENT are fit in
> -  // one page (2MB). Then we don't need to update attributes for 
> pages
> -  // crossing page directory. ASSERT below is for that purpose.
> -  //
> -  ASSERT (Index < EFI_PAGE_SIZE/sizeof (UINT64));
> -
> -  PageTable[Index] &= ~(UINT64)IA32_PG_RW;
> -  PoolUnitSize -= LevelSize[Level];
> -
> -  ++Index;
> -}
> -  }
> -
> -  break;
> -} else {
> -  //
> -  // The smaller granularity of page must be needed.
> -  //
> -  ASSERT (Level > 1);
> -
> -  NewPageTable = AllocatePageTableMemory

Re: [edk2-devel] [Patch V2 6/8] MdeModulePkg/DxeIpl: Create page table by CpuPageTableLib

2023-03-31 Thread Ni, Ray

Reviewed-by: Ray Ni 

> -Original Message-
> From: Tan, Dun 
> Sent: Friday, March 31, 2023 5:34 PM
> To: devel@edk2.groups.io
> Cc: Bi, Dandan ; Gao, Liming
> ; Ni, Ray ; Wang, Jian J
> 
> Subject: [Patch V2 6/8] MdeModulePkg/DxeIpl: Create page table by
> CpuPageTableLib
> 
> Modify CreateIdentityMappingPageTables() to create page table
> based on CpuPageTableLib in DxeIpl module. This function can
> be used to create both IA32 PAE paging and long mode 4-level,
> 5-level paging structure. With the PageTableMap() API in the
> CpuPageTableLib, we can remove the complicated page table
> manipulating code. This commit doesn't change any functionality.
> 
> Signed-off-by: Dun Tan 
> Cc: Dandan Bi 
> Cc: Liming Gao 
> Cc: Ray Ni 
> Cc: Jian J Wang 
> ---
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h|   3 ++-
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |   4 +++-
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  | 109 ---
> --
>  MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |   5 +++--
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 558
> ++
> ++
> +---
> --
> --
> --
> 
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 167
> ++--
> ---
>  6 files changed, 167 insertions(+), 679 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> index 2f015befce..03e6f8cff7 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> @@ -2,7 +2,7 @@
>Master header file for DxeIpl PEIM. All source files in this module should
>include this file for common definitions.
> 
> -Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -42,6 +42,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #define STACK_SIZE  0x2
>  #define BSP_STORE_SIZE  0x4000
> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> index 052ea0ec1a..60623b4f66 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> @@ -5,7 +5,7 @@
>  #  PPI to discover and dispatch the DXE Foundation and components that are
>  #  needed to run the DXE Foundation.
>  #
> -#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.
>  #  Copyright (c) 2017, AMD Incorporated. All rights reserved.
>  #  Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights
> reserved.
>  #  Copyright (c) 2022, Loongson Technology Corporation Limited. All rights
> reserved.
> @@ -60,6 +60,7 @@
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> +  UefiCpuPkg/UefiCpuPkg.dec
> 
>  [Packages.ARM, Packages.AARCH64]
>ArmPkg/ArmPkg.dec
> @@ -79,6 +80,7 @@
>DebugAgentLib
>PeiServicesTablePointerLib
>PerformanceLib
> +  CpuPageTableLib
> 
>  [LibraryClasses.ARM, LibraryClasses.AARCH64]
>ArmMmuLib
> diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> index fdeaaa39d8..af1e1e3d02 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> +++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> @@ -1,7 +1,7 @@
>  /** @file
>Ia32-specific functionality for DxeLoad.
> 
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.
>  Copyright (c) 2017, AMD Incorporated. All rights reserved.
> 
>  SPDX-License-Identifier: BSD-2-Clause-Patent
> @@ -70,107 +70,6 @@ GLOBAL_REMOVE_IF_UNREFERENCED
> IA32_DESCRIPTOR  gLidtDescriptor = {
>0
>  };
> 
> -/**
> -  Allocates and fills in the Page Directory and Page Table Entries to
> -  establish a 4G page table.
> -
> -  @param[in] StackBase  Stack base address.
> -  @param[in] StackSize  Stack size.
> -
> -  @return The address of page table.
> -
> -**/
> -UINTN
> -Create4GPageTablesIa32Pae (
> -  IN EFI_PHYSICAL_ADDRESS  StackBase,
> -  IN

Re: [edk2-devel] [Patch V2 1/8] EmulatorPkg: Add CpuPageTableLib required by DxeIpl in DSC

2023-03-31 Thread Ni, Ray

Reviewed-by: Ray Ni 

> -Original Message-
> From: Tan, Dun 
> Sent: Friday, March 31, 2023 5:34 PM
> To: devel@edk2.groups.io
> Cc: Andrew Fish ; Ni, Ray 
> Subject: [Patch V2 1/8] EmulatorPkg: Add CpuPageTableLib required by
> DxeIpl in DSC
> 
> Add CpuPageTableLib instance required by DxeIpl in EmulatorPkg.dsc.
> 
> Signed-off-by: Dun Tan 
> Cc: Andrew Fish 
> Cc: Ray Ni 
> ---
>  EmulatorPkg/EmulatorPkg.dsc | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
> index b44435d7e6..d1fb9d9256 100644
> --- a/EmulatorPkg/EmulatorPkg.dsc
> +++ b/EmulatorPkg/EmulatorPkg.dsc
> @@ -4,7 +4,7 @@
>  # The Emulation Platform can be used to debug individual modules, prior to
> creating
>  # a real platform. This also provides an example for how an DSC is created.
>  #
> -# Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
> +# Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.
>  # Portions copyright (c) 2010 - 2011, Apple Inc. All rights reserved.
>  # Copyright (c) Microsoft Corporation.
>  #
> @@ -66,6 +66,7 @@
> 
> PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/Base
> PeCoffGetEntryPointLib.inf
>BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> 
> FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBuffer
> BltLib.inf
> +
> CpuPageTableLib|UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableLib.inf
> 
>#
># UEFI & PI
> --
> 2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102289): https://edk2.groups.io/g/devel/message/102289
Mute This Topic: https://groups.io/mt/97969851/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] [RFT PATCH v3 3/5] UefiCpuPkg/CpuExceptionHandlerLib: Make runtime fixups XCODE-only

2023-03-31 Thread Ni, Ray

Ok I see that the macro is added to PP flags.
I thought it's added to NASM build flags.

Reviewed-by: Ray Ni 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ard
> Biesheuvel
> Sent: Friday, March 31, 2023 5:15 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Ni, Ray ; Andrew
> Fish ; Kinney, Michael D ;
> Liu, Zhiguang ; Rebecca Cran
> ; Tom Lendacky ;
> Marvin Häuser 
> Subject: [edk2-devel] [RFT PATCH v3 3/5]
> UefiCpuPkg/CpuExceptionHandlerLib: Make runtime fixups XCODE-only
> 
> The CPU exception handler library code was rewritten at some point to
> populate the vector code templates with absolute references at runtime,
> given that the XCODE linker does not permit absolute references in
> executable code when creating PIE executables.
> 
> This is rather unfortunate, as this prevents us from using strict
> permissions on the memory mappings, given that the .text section needs
> to be writable at runtime for this arrangement to work.
> 
> So let's make this hack XCODE-only, by setting a preprocessor #define
> from the command line when using the XCODE toolchain, and only including
> the runtime fixup code when the macro is defined.
> 
> While at it, rename the Xcode5ExceptionHandlerAsm.nasm source file and
> drop the Xcode5 prefix: this code is used by other toolchains too.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.in
> f|  5 -
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
> |  4 +++-
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.i
> nf|  4 +++-
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/{Xcode5ExceptionHandler
> Asm.nasm => ExceptionHandlerAsm.nasm} | 10 ++
>  4 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.
> inf
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib
> .inf
> index d0f82095cf926e99..ee9df805c05df4f7 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.
> inf
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib
> .inf
> @@ -28,7 +28,7 @@ [Sources.Ia32]
>Ia32/ArchInterruptDefs.h
> 
> 
> 
>  [Sources.X64]
> 
> -  X64/Xcode5ExceptionHandlerAsm.nasm
> 
> +  X64/ExceptionHandlerAsm.nasm
> 
>X64/ArchExceptionHandler.c
> 
>X64/ArchInterruptDefs.h
> 
> 
> 
> @@ -61,3 +61,6 @@ [LibraryClasses]
>MemoryAllocationLib
> 
>DebugLib
> 
>CcExitLib
> 
> +
> 
> +[BuildOptions]
> 
> +  XCODE:*_*_X64_PP_FLAGS = -DNO_ABSOLUTE_RELOCS_IN_TEXT
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.i
> nf
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.i
> nf
> index 5339f8e604045801..83970c54712f22a2 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.i
> nf
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.i
> nf
> @@ -28,7 +28,7 @@ [Sources.Ia32]
>Ia32/ArchInterruptDefs.h
> 
> 
> 
>  [Sources.X64]
> 
> -  X64/Xcode5ExceptionHandlerAsm.nasm
> 
> +  X64/ExceptionHandlerAsm.nasm
> 
>X64/ArchExceptionHandler.c
> 
>X64/ArchInterruptDefs.h
> 
> 
> 
> @@ -62,3 +62,5 @@ [Pcd]
>  [FeaturePcd]
> 
>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackGuard##
> CONSUMES
> 
> 
> 
> +[BuildOptions]
> 
> +  XCODE:*_*_X64_PP_FLAGS = -DNO_ABSOLUTE_RELOCS_IN_TEXT
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLi
> b.inf
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLi
> b.inf
> index 8f8a5dab79303f87..acd2936aef4490a5 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLi
> b.inf
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLi
> b.inf
> @@ -28,7 +28,7 @@ [Sources.Ia32]
>Ia32/ArchInterruptDefs.h
> 
> 
> 
>  [Sources.X64]
> 
> -  X64/Xcode5ExceptionHandlerAsm.nasm
> 
> +  X64/ExceptionHandlerAsm.nasm
> 
>X64/ArchExceptionHandler.c
> 
>X64/ArchInterruptDefs.h
> 
> 
> 
> @@ -61,3 +61,5 @@ [Pcd]
>  [FeaturePcd]
> 
>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackGuard##
> CONSUMES
> 
> 
> 
> +[BuildOptions]
> 
> +  XCODE:*_*_X64_PP_FLAGS = -DNO_ABSOLUTE_RELOCS_IN_TEXT
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandle
> rAsm.nasm
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.n
> asm
> similarity index 95%
> rename from
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandlerA
> sm.nasm
> rename to
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nas
> m
> index 957478574253e619..3823656ea7d4c3b8 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandle
> rAsm.nasm
> +++
>

Re: [edk2-devel] [RFT PATCH v3 2/5] UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version

2023-03-31 Thread Ni, Ray



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ard
> Biesheuvel
> Sent: Friday, March 31, 2023 6:13 PM
> To: devel@edk2.groups.io; Ni, Ray 
> Cc: Andrew Fish ; Kinney, Michael D
> ; Liu, Zhiguang ;
> Rebecca Cran ; Tom Lendacky
> ; Marvin Häuser 
> Subject: Re: [edk2-devel] [RFT PATCH v3 2/5]
> UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version
> 
> On Fri, 31 Mar 2023 at 11:56, Ni, Ray  wrote:
> >
> > Ard,
> > Thanks for the detailed commit messages. That really helps me to
> understand why XCODE version
> > was needed.
> >
> > However, I feel it would be great if you can "highlight" what are changed by
> this patch.
> > The following is just an example. You can reword as you like.
> >
> > 1. Change for non-XCODE SecPeiCpuExceptionHandlerLib:
> >* Use SecPeiExceptionHandlerAsm.nasm (renamed from
> ExceptionHandlerAsm.nasm)
> >* Removed some unnecessary absolute references
> >* (32 IDT stubs are still in .text.)
> 
> Indeed
> 
> > 2. Change for XCODE SecPeiCpuExceptionHandlerLib:
> >* Use SecPeiExceptionHandlerAsm.nasm instead of
> Xcode5ExceptionHandlerAsm.nasm
> >* CET logic is not in SecPeiExceptionHandlerAsm.nasm (but aligns to non-
> XCODE lib instance)
> 
> No, this does not actually change in this patch. The CET logic does
> not exist in the generic SecPei version either before or after this
> patch.

Because of this patch, CET logic is removed from XCODE 
SecPeiCpuExceptionHandlerLib.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102287): https://edk2.groups.io/g/devel/message/102287
Mute This Topic: https://groups.io/mt/97969650/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] [RFT PATCH v3 2/5] UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version

2023-03-31 Thread Ard Biesheuvel

On Fri, 31 Mar 2023 at 12:16, Ni, Ray  wrote:
>
> So, for nasm advanced macros (rep), use "%". Otherwise, either is fine.
>

Exactly. These are preprocessor macros, not nasm macros.


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

Re: [edk2-devel] [RFT PATCH v3 2/5] UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version

2023-03-31 Thread Ni, Ray

So, for nasm advanced macros (rep), use "%". Otherwise, either is fine.


> -Original Message-
> From: Ard Biesheuvel 
> Sent: Friday, March 31, 2023 6:14 PM
> To: Ni, Ray 
> Cc: devel@edk2.groups.io; Andrew Fish ; Kinney,
> Michael D ; Liu, Zhiguang
> ; Rebecca Cran ; Tom
> Lendacky ; Marvin Häuser
> 
> Subject: Re: [edk2-devel] [RFT PATCH v3 2/5]
> UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version
> 
> On Fri, 31 Mar 2023 at 11:58, Ni, Ray  wrote:
> >
> > By the way, which ("%" or "#") should be used for def check in NASM?
> > I thought we need to use "%" but your patch uses "#".
> >
> 
> The build rule for NASM files is
> 
> Trim --asm-file -o ${d_path}(+)${s_base}.i -i $(INC_LIST) ${src}
> "$(PP)" $(DEPS_FLAGS) $(PP_FLAGS) $(INC) ${src} >
> ${d_path}(+)${s_base}.ii
> Trim --trim-long --source-code -o ${d_path}(+)${s_base}.iii
> ${d_path}(+)${s_base}.ii
> "$(NASM)" -I${s_path}(+) $(NASM_INC) $(NASM_FLAGS) -o $dst
> ${d_path}(+)${s_base}.iii
> 
> So the preprocessor $(PP) is executed first, which takes care of the #ifdefs


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102285): https://edk2.groups.io/g/devel/message/102285
Mute This Topic: https://groups.io/mt/97969650/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] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify CpuExceptionHandlerLib

2023-03-31 Thread Ard Biesheuvel

On Fri, 31 Mar 2023 at 12:09, Ni, Ray  wrote:
>
> Ard,
> What does "-read_only_relocs suppress" control?
> Linker doesn't produce relocation entries that modifies .text section silently
> so the final .text just cannot run at all?
>

Yeah, good question. So this is why I dropped this now - it doesn't
work as expected.


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

Re: [edk2-devel] [RFT PATCH v3 2/5] UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version

2023-03-31 Thread Ard Biesheuvel

On Fri, 31 Mar 2023 at 11:58, Ni, Ray  wrote:
>
> By the way, which ("%" or "#") should be used for def check in NASM?
> I thought we need to use "%" but your patch uses "#".
>

The build rule for NASM files is

Trim --asm-file -o ${d_path}(+)${s_base}.i -i $(INC_LIST) ${src}
"$(PP)" $(DEPS_FLAGS) $(PP_FLAGS) $(INC) ${src} >
${d_path}(+)${s_base}.ii
Trim --trim-long --source-code -o ${d_path}(+)${s_base}.iii
${d_path}(+)${s_base}.ii
"$(NASM)" -I${s_path}(+) $(NASM_INC) $(NASM_FLAGS) -o $dst
${d_path}(+)${s_base}.iii

So the preprocessor $(PP) is executed first, which takes care of the #ifdefs


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

Re: [edk2-devel] [RFT PATCH v3 2/5] UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version

2023-03-31 Thread Ard Biesheuvel

On Fri, 31 Mar 2023 at 11:56, Ni, Ray  wrote:
>
> Ard,
> Thanks for the detailed commit messages. That really helps me to understand 
> why XCODE version
> was needed.
>
> However, I feel it would be great if you can "highlight" what are changed by 
> this patch.
> The following is just an example. You can reword as you like.
>
> 1. Change for non-XCODE SecPeiCpuExceptionHandlerLib:
>* Use SecPeiExceptionHandlerAsm.nasm (renamed from 
> ExceptionHandlerAsm.nasm)
>* Removed some unnecessary absolute references
>* (32 IDT stubs are still in .text.)

Indeed

> 2. Change for XCODE SecPeiCpuExceptionHandlerLib:
>* Use SecPeiExceptionHandlerAsm.nasm instead of 
> Xcode5ExceptionHandlerAsm.nasm
>* CET logic is not in SecPeiExceptionHandlerAsm.nasm (but aligns to 
> non-XCODE lib instance)

No, this does not actually change in this patch. The CET logic does
not exist in the generic SecPei version either before or after this
patch.

Only the Xcode version is changed, because that version uses the same
as the Dxe/Smm version, which does have the CET code.

>* Fixed a bug that does runtime fixup in TEXT section in SPI flash.
>* Emitted the code carrying the absolute symbol references into the .data 
> which XCODE or
>   LLD linkers allow.
>  Then fixup can be done by other build tools such as GenFv if the code 
> runs in SPI flash,
>  or by PE coff loader if the code is loaded to memory.
>
> Again, thanks for the quick patches just because I asked some XCODE questions.
>

No problem. I'd like to get this fixed too for OVMF.


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

Re: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify CpuExceptionHandlerLib

2023-03-31 Thread Ni, Ray

Ard,
What does "-read_only_relocs suppress" control?
Linker doesn't produce relocation entries that modifies .text section silently
so the final .text just cannot run at all?

Thanks,
Ray

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ard
> Biesheuvel
> Sent: Friday, March 31, 2023 5:15 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Ni, Ray ; Andrew
> Fish ; Kinney, Michael D ;
> Liu, Zhiguang ; Rebecca Cran
> ; Tom Lendacky ;
> Marvin Häuser 
> Subject: [edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify
> CpuExceptionHandlerLib
> 
> We have a special version of CpuExceptionHandlerLib for XCODE5, whose
> 
> linker (LLD) does not permit absolute symbol references in read-only
> 
> sections.
> 
> 
> 
> Instead of fixing this up at runtime for all toolchains (which is done
> 
> by writing the fixed up values to the .text section, which we'd prefer
> 
> to avoid), tweak the SEC/PEI version so it does not need this, and
> 
> update the remaining versions to only incorporate this logic when using
> 
> the XCODE toolchain.
> 
> 
> 
> Changes since v3:
> 
> -  As Marvin points out, using '-read_only_relocs suppress' with the X64
> 
>XCODE linker is a terrible idea, as it corrupts the resulting PE
> 
>binaries, so instead, let's do the following:
> 
>. tweak the SEC/PEI version of the library so the relocs are emitted
> 
>  into .data when using XCODE;
> 
>. tweak the other versions so the runtime fixups are only done when
> 
>  using XCODE
> 
> - add acks from Jiewen and Ray
> 
> 
> 
> Changes since v2:
> 
> - pass linker switches to permit absolute relocations in read-only
> 
>   regions, and keep all code in .text
> 
> 
> 
> Cc: "Ni, Ray" 
> 
> Cc: Andrew Fish 
> 
> Cc: "Kinney, Michael D" 
> 
> Cc: "Liu, Zhiguang" 
> 
> Cc: Rebecca Cran 
> 
> Cc: Tom Lendacky 
> 
> Cc: Marvin HÃ¤user 
> 
> 
> 
> Ard Biesheuvel (5):
> 
>   BaseTools/tools_def CLANGDWARF: Permit text relocations
> 
>   UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version
> 
>   UefiCpuPkg/CpuExceptionHandlerLib: Make runtime fixups XCODE-only
> 
>   OvmfPkg: Drop special Xcode5 version of exception handler library
> 
>   UefiCpuPkg/CpuExceptionHandlerLib: Drop special XCODE5 version
> 
> 
> 
>  BaseTools/Conf/tools_def.template
> |   2 +-
> 
>  OvmfPkg/AmdSev/AmdSevX64.dsc
> |   4 -
> 
>  OvmfPkg/CloudHv/CloudHvX64.dsc
> |   4 -
> 
>  OvmfPkg/IntelTdx/IntelTdxX64.dsc 
> |
> 4 -
> 
>  OvmfPkg/Microvm/MicrovmX64.dsc
> |   4 -
> 
>  OvmfPkg/OvmfPkgIa32.dsc  
> |   4
> -
> 
>  OvmfPkg/OvmfPkgIa32X64.dsc   
> |
> 4 -
> 
>  OvmfPkg/OvmfPkgX64.dsc   
> |   4
> -
> 
>  OvmfPkg/OvmfXen.dsc  
> |   4 -
> 
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.in
> f  |   5 +-
> 
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
> |   4 +-
> 
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib
> .inf   |   4 +-
> 
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.i
> nf  |   4 +-
> 
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nas
> m   | 116 +---
> 
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/{Xcode5ExceptionHandler
> Asm.nasm => SecPeiExceptionHandlerAsm.nasm} | 108 +++---
> 
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHa
> ndlerLib.inf |  65 ---
> 
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHa
> ndlerLib.uni |  18 ---
> 
>  UefiCpuPkg/UefiCpuPkg.dsc
> |   7
> --
> 
>  18 files changed, 133 insertions(+), 232 deletions(-)
> 
>  rename
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/{Xcode5ExceptionHandler
> Asm.nasm => SecPeiExceptionHandlerAsm.nasm} (70%)
> 
>  delete mode 100644
> UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHa
> ndlerLib.inf
> 
>  delete mode 100644
> UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHa
> ndlerLib.uni
> 
> 
> 
> --
> 
> 2.39.2
> 
> 
> 
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#102255):
> https://edk2.groups.io/g/devel/message/102255
> Mute This Topic: https://groups.io/mt/97969646/1712937
> Group Owner:

Re: [edk2-devel] [RFT PATCH v3 3/5] UefiCpuPkg/CpuExceptionHandlerLib: Make runtime fixups XCODE-only

2023-03-31 Thread Ni, Ray



I like this approach that allows "relocation entry guided" fixups done by 
either GenFv or PE loader.

Only concern is which to use between "#" and "%".

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ard
> Biesheuvel
> Sent: Friday, March 31, 2023 5:15 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Ni, Ray ; Andrew
> Fish ; Kinney, Michael D ;
> Liu, Zhiguang ; Rebecca Cran
> ; Tom Lendacky ;
> Marvin Häuser 
> Subject: [edk2-devel] [RFT PATCH v3 3/5]
> UefiCpuPkg/CpuExceptionHandlerLib: Make runtime fixups XCODE-only
> 
> The CPU exception handler library code was rewritten at some point to
> populate the vector code templates with absolute references at runtime,
> given that the XCODE linker does not permit absolute references in
> executable code when creating PIE executables.
> 
> This is rather unfortunate, as this prevents us from using strict
> permissions on the memory mappings, given that the .text section needs
> to be writable at runtime for this arrangement to work.
> 
> So let's make this hack XCODE-only, by setting a preprocessor #define
> from the command line when using the XCODE toolchain, and only including
> the runtime fixup code when the macro is defined.
> 
> While at it, rename the Xcode5ExceptionHandlerAsm.nasm source file and
> drop the Xcode5 prefix: this code is used by other toolchains too.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.in
> f|  5 -
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
> |  4 +++-
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.i
> nf|  4 +++-
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/{Xcode5ExceptionHandler
> Asm.nasm => ExceptionHandlerAsm.nasm} | 10 ++
>  4 files changed, 20 insertions(+), 3 deletions(-)
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.
> inf
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib
> .inf
> index d0f82095cf926e99..ee9df805c05df4f7 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.
> inf
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib
> .inf
> @@ -28,7 +28,7 @@ [Sources.Ia32]
>Ia32/ArchInterruptDefs.h
> 
> 
> 
>  [Sources.X64]
> 
> -  X64/Xcode5ExceptionHandlerAsm.nasm
> 
> +  X64/ExceptionHandlerAsm.nasm
> 
>X64/ArchExceptionHandler.c
> 
>X64/ArchInterruptDefs.h
> 
> 
> 
> @@ -61,3 +61,6 @@ [LibraryClasses]
>MemoryAllocationLib
> 
>DebugLib
> 
>CcExitLib
> 
> +
> 
> +[BuildOptions]
> 
> +  XCODE:*_*_X64_PP_FLAGS = -DNO_ABSOLUTE_RELOCS_IN_TEXT
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.i
> nf
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.i
> nf
> index 5339f8e604045801..83970c54712f22a2 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.i
> nf
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.i
> nf
> @@ -28,7 +28,7 @@ [Sources.Ia32]
>Ia32/ArchInterruptDefs.h
> 
> 
> 
>  [Sources.X64]
> 
> -  X64/Xcode5ExceptionHandlerAsm.nasm
> 
> +  X64/ExceptionHandlerAsm.nasm
> 
>X64/ArchExceptionHandler.c
> 
>X64/ArchInterruptDefs.h
> 
> 
> 
> @@ -62,3 +62,5 @@ [Pcd]
>  [FeaturePcd]
> 
>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackGuard##
> CONSUMES
> 
> 
> 
> +[BuildOptions]
> 
> +  XCODE:*_*_X64_PP_FLAGS = -DNO_ABSOLUTE_RELOCS_IN_TEXT
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLi
> b.inf
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLi
> b.inf
> index 8f8a5dab79303f87..acd2936aef4490a5 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLi
> b.inf
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLi
> b.inf
> @@ -28,7 +28,7 @@ [Sources.Ia32]
>Ia32/ArchInterruptDefs.h
> 
> 
> 
>  [Sources.X64]
> 
> -  X64/Xcode5ExceptionHandlerAsm.nasm
> 
> +  X64/ExceptionHandlerAsm.nasm
> 
>X64/ArchExceptionHandler.c
> 
>X64/ArchInterruptDefs.h
> 
> 
> 
> @@ -61,3 +61,5 @@ [Pcd]
>  [FeaturePcd]
> 
>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackGuard##
> CONSUMES
> 
> 
> 
> +[BuildOptions]
> 
> +  XCODE:*_*_X64_PP_FLAGS = -DNO_ABSOLUTE_RELOCS_IN_TEXT
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandle
> rAsm.nasm
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.n
> asm
> similarity index 95%
> rename from
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandlerA
> sm.nasm
> rename to
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nas
> m
> index 957478574253e619..3823656ea7d4c3b8 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandle

[edk2-devel] [PATCH v2 2/2] OvmfPkg/RiscVVirt: Enable CMO support

2023-03-31 Thread Dhaval Sharma

Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Sunil V L 
Cc: Andrei Warkentin 
Signed-off-by: Dhaval Sharma 

Add support for Cache Management Operations by conditionally
adding CMO library.
---

Notes:
v2:
- Updated RiscVCMOCacheManagementLib as a separate CMO library

 OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc | 9 +
 1 file changed, 9 insertions(+)

diff --git a/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc 
b/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc
index 28d9af4d79b9..16c714625870 100644
--- a/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc
+++ b/OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc
@@ -46,6 +46,12 @@ [Defines]
   DEFINE NETWORK_ALLOW_HTTP_CONNECTIONS = TRUE
   DEFINE NETWORK_ISCSI_ENABLE   = FALSE
 
+#
+# CMO support for RV. It depends on 2 factors. First support in compiler
+# GCC:Binutils 2.39 (GCC12.2+) is required.
+#
+  DEFINE RV_CMO_FEATURE_AVAILABLE = FALSE
+
 !if $(NETWORK_SNP_ENABLE) == TRUE
   !error "NETWORK_SNP_ENABLE is IA32/X64/EBC only"
 !endif
@@ -112,6 +118,9 @@ [LibraryClasses.common]
   
TpmPlatformHierarchyLib|SecurityPkg/Library/PeiDxeTpmPlatformHierarchyLibNull/PeiDxeTpmPlatformHierarchyLib.inf
 !endif
 
+!if $(RV_CMO_FEATURE_AVAILABLE) == TRUE
+   
CacheMaintenanceLib|MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCacheMaintenanceLib.inf
+!endif
 [LibraryClasses.common.DXE_DRIVER]
   
ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
   
PciExpressLib|OvmfPkg/Library/BaseCachingPciExpressLib/BaseCachingPciExpressLib.inf
-- 
2.40.0.rc0.57.g454dfcbddf



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102279): https://edk2.groups.io/g/devel/message/102279
Mute This Topic: https://groups.io/mt/97970175/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] WIP: MdePkg/RiscVCMOCacheMaintenanceLib:Enable RISCV CMO

2023-03-31 Thread Dhaval Sharma

Adding code to support Cache Management Operations
(CMO) defined by RV spec https://github.com/riscv/riscv-CMOs
Notes:
1. CMO only supports block based Operations. Meaning complete
cache flush/invd/clean Operations are not available
2. Current implementation uses ifence instructions but it
maybe platform specific. Many platforms may not support cache
Operations based on fence.i
3. For now adding CMO on top of fence.i as it is not supposed to
have any adverse effect on CMO operation.
4. This requires support for GCC12.2 onwards.

Test:
1. Ensured correct instructions are refelecting in asm
2. Able to boot platform with RiscVVirtQemu config
3. Not able to verify actual instruction in HW as Qemu ignores
any actual cache operations.

Cc: Sunil V L 
Cc: Andrei Warkentin 
Cc: Da  Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: niel Schaefer 

Signed-off-by: Dhaval Sharma 
---

Notes:
v2:
- Added separate CMO Lib to RiscV instead of mixing it up
  with existing BaseCacheMaintenanceLib that has fence.i based
  implementation. With this we have flexibility to chose the
  library based on configurable option in dsc.

 MdePkg/MdePkg.dsc  |   
1 +
 MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCacheMaintenanceLib.inf |  
30 ++
 MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCache.c | 
377 
 MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCacheMaintenanceLib.uni |  
11 +
 MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCpuCMOCache.S  |  
23 ++
 5 files changed, 442 insertions(+)

diff --git a/MdePkg/MdePkg.dsc b/MdePkg/MdePkg.dsc
index 0ac7618b4623..78870c916433 100644
--- a/MdePkg/MdePkg.dsc
+++ b/MdePkg/MdePkg.dsc
@@ -192,5 +192,6 @@ [Components.ARM, Components.AARCH64]
 
 [Components.RISCV64]
   MdePkg/Library/BaseRiscVSbiLib/BaseRiscVSbiLib.inf
+  MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCacheMaintenanceLib.inf
 
 [BuildOptions]
diff --git 
a/MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCacheMaintenanceLib.inf 
b/MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCacheMaintenanceLib.inf
new file mode 100644
index ..b36a0d97332b
--- /dev/null
+++ b/MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCacheMaintenanceLib.inf
@@ -0,0 +1,30 @@
+## @file
+#  RISCV64 CMO Cache Maintenance Library implementation.
+#
+#  Copyright (c) 2023, Rivos Inc. All rights reserved.
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = RiscVCMOCacheMaintenanceLib
+  MODULE_UNI_FILE= RiscVCMOCacheMaintenanceLib.uni
+  FILE_GUID  = 6F651f1F-CAD5-4059-B1CE-7E60BC624757
+  MODULE_TYPE= BASE
+  VERSION_STRING = 1.1
+  LIBRARY_CLASS  = RiscVCMOCacheMaintenanceLib
+
+#
+#  VALID_ARCHITECTURES   = RISCV64
+#
+
+[Sources]
+  RiscVCMOCache.c
+  RiscVCpuCMOCache.S   | GCC
+
+[Packages]
+  MdePkg/MdePkg.dec
+
+[LibraryClasses]
+  DebugLib
diff --git a/MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCache.c 
b/MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCache.c
new file mode 100644
index ..37ce294dbabf
--- /dev/null
+++ b/MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCache.c
@@ -0,0 +1,377 @@
+/** @file
+  RISC-V specific functionality for cache.
+
+  Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
reserved.
+  Copyright (c) 2023, Rivos Inc. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include 
+#include 
+
+/**
+  Use runtime discovery mechanism in future when avalable
+  through https://lists.riscv.org/g/tech-privileged/topic/83853282
+**/
+#define RV64_CACHE_BLOCK_SIZE  64
+
+typedef enum {
+  Clean,
+  Flush,
+  Invld,
+} CACHE_OP;
+
+/* Ideally we should do this through BaseLib.h by adding
+   Asm*CacheLine functions. This can be done after Initial
+   RV refactoring is complete. For now call functions directly
+*/
+VOID
+EFIAPI
+RiscVCpuCacheFlush (
+  UINTN
+  );
+
+VOID
+EFIAPI
+RiscVCpuCacheClean (
+  UINTN
+  );
+
+VOID
+EFIAPI
+RiscVCpuCacheInval (
+  UINTN
+  );
+
+/**
+  Performs required opeartion on cache lines in the cache coherency domain
+  of the calling CPU. If Address is not aligned on a cache line boundary,
+  then entire cache line containing Address is operated. If Address + Length
+  is not aligned on a cache line boundary, then the entire cache line
+  containing Address + Length -1 is operated.
+
+  If Length is greater than (MAX_ADDRESS - Address + 1), then ASSERT().
+
+  @param  Address The base address of the cache lines to
+  invalidate. If the CPU is in a physical addressing mode,
+  then Address is a physical address. If the CPU is in a virtual
+  addressing mode, then Address is a virtual address.
+
+  @param  Length  The number of

[edk2-devel] [PATCH v2 0/2] WIP: Enable CMO support for RiscV64

2023-03-31 Thread Dhaval Sharma

Current implementation for cache management (instruction/data flush/invd)
depends on fence.i instruction. All RV platforms may not use the same
method for cache management. Instead RV defines CMO Cache management
operations specification which consits of cbo.x instructions for cache
management. However it requires GCC12+ to enable the same. Need to decide
how cbo based implementation coexists with ifence based implementation
with GCC version dependency.

This patchset is primarily to review the same and decide path forward.
review branch: https://github.com/rivosinc/edk2/tree/dev_rv_cmo_v3


Dhaval Sharma (2):
  WIP: MdePkg/RiscVCMOCacheMaintenanceLib:Enable RISCV CMO
  OvmfPkg/RiscVVirt: Enable CMO support

 MdePkg/MdePkg.dsc  |   
1 +
 OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc|   
9 +
 MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCacheMaintenanceLib.inf |  
30 ++
 MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCache.c | 
377 
 MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCacheMaintenanceLib.uni |  
11 +
 MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCpuCMOCache.S  |  
23 ++
 6 files changed, 451 insertions(+)
 create mode 100644 
MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCacheMaintenanceLib.inf
 create mode 100644 MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCache.c
 create mode 100644 
MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCMOCacheMaintenanceLib.uni
 create mode 100644 
MdePkg/Library/RiscVCMOCacheMaintenanceLib/RiscVCpuCMOCache.S

-- 
2.40.0.rc0.57.g454dfcbddf



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

Re: [edk2-devel] [RFT PATCH v3 2/5] UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version

2023-03-31 Thread Ni, Ray

By the way, which ("%" or "#") should be used for def check in NASM?
I thought we need to use "%" but your patch uses "#".

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ni, Ray
> Sent: Friday, March 31, 2023 5:56 PM
> To: Ard Biesheuvel ; devel@edk2.groups.io
> Cc: Andrew Fish ; Kinney, Michael D
> ; Liu, Zhiguang ;
> Rebecca Cran ; Tom Lendacky
> ; Marvin Häuser 
> Subject: Re: [edk2-devel] [RFT PATCH v3 2/5]
> UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version
> 
> Ard,
> Thanks for the detailed commit messages. That really helps me to
> understand why XCODE version
> was needed.
> 
> However, I feel it would be great if you can "highlight" what are changed by
> this patch.
> The following is just an example. You can reword as you like.
> 
> 1. Change for non-XCODE SecPeiCpuExceptionHandlerLib:
>* Use SecPeiExceptionHandlerAsm.nasm (renamed from
> ExceptionHandlerAsm.nasm)
>* Removed some unnecessary absolute references
>* (32 IDT stubs are still in .text.)
> 2. Change for XCODE SecPeiCpuExceptionHandlerLib:
>* Use SecPeiExceptionHandlerAsm.nasm instead of
> Xcode5ExceptionHandlerAsm.nasm
>* CET logic is not in SecPeiExceptionHandlerAsm.nasm (but aligns to non-
> XCODE lib instance)
>* Fixed a bug that does runtime fixup in TEXT section in SPI flash.
>* Emitted the code carrying the absolute symbol references into the .data
> which XCODE or
>   LLD linkers allow.
>  Then fixup can be done by other build tools such as GenFv if the code 
> runs
> in SPI flash,
>  or by PE coff loader if the code is loaded to memory.
> 
> Again, thanks for the quick patches just because I asked some XCODE
> questions.
> 
> Thanks,
> Ray
> 
> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Friday, March 31, 2023 5:15 PM
> > To: devel@edk2.groups.io
> > Cc: Ard Biesheuvel ; Ni, Ray ;
> Andrew
> > Fish ; Kinney, Michael D ;
> > Liu, Zhiguang ; Rebecca Cran
> > ; Tom Lendacky ;
> > Marvin Häuser 
> > Subject: [RFT PATCH v3 2/5] UefiCpuPkg/CpuExceptionHandlerLib: Use
> single
> > SEC/PEI version
> >
> > Currently, we use the non-Xcode5 version of ExceptionHandlerAsm.nasm
> > only for the SEC and PEI phases, and this version was not compatible
> > with the XCODE or LLD linkers, which do not permit absolute relocations
> > in read-only sections.
> >
> > Given that SEC and PEI code typically executes in place from flash and
> > does not use page alignment for sections, we can simply emit the code
> > carrying the absolute symbol references into the .data segment instead.
> > This works around the linker's objections, and the resulting image will
> > be mapped executable in its entirety anyway. Since this is only needed
> > for XCODE, let's make this change conditionally using a preprocessor
> > macro.
> >
> > Let's rename the .nasm file to reflect the fact that is used for the
> > SecPei flavor of this library only, and while at it, remove some
> > unnecessary absolute references.
> >
> > Also update the Xcode specific version of this library, and use this
> > source file instead. This is necesessary, as the Xcode specific version
> > modifies its own code at runtime, which is not permitted in SEC or PEI.
> > Note that this also removes CET support from the Xcode5 specific build
> > of the SEC/PEI version of this library, but this is not needed this
> > early in any case, and this aligns it with other toolchains, which use
> > this version of the library, which does not have CET support either.
> >
> > Signed-off-by: Ard Biesheuvel 
> > ---
> >
> >
> UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib
> > .inf |  4 +++-
> >
> >
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/{ExceptionHandlerAsm.na
> > sm => SecPeiExceptionHandlerAsm.nasm} | 12 
> >
> >
> UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHa
> > ndlerLib.inf   |  4 +++-
> >  3 files changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git
> >
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandler
> > Lib.inf
> >
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandler
> > Lib.inf
> > index df44371fe018e06d..885bb6638ab58620 100644
> > ---
> >
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandler
> > Lib.inf
> > +++
> >
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandler
> > Lib.inf
> > @@ -28,7 +28,7 @@ [Sources.Ia32]
> >Ia32/ArchInterruptDefs.h
> >
> >
> >
> >  [Sources.X64]
> >
> > -  X64/ExceptionHandlerAsm.nasm
> >
> > +  X64/SecPeiExceptionHandlerAsm.nasm
> >
> >X64/ArchExceptionHandler.c
> >
> >X64/ArchInterruptDefs.h
> >
> >
> >
> > @@ -58,3 +58,5 @@ [Pcd]
> >  [FeaturePcd]
> >
> >gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackGuard##
> > CONSUMES
> >
> >
> >
> > +[BuildOptions]
> >
> > +  XCODE:*_*_X64_PP_FLAGS = -DNO_ABSOLUTE_RELOCS_IN_TEXT
> >
> > diff --git
>

Re: [edk2-devel] [RFT PATCH v3 2/5] UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version

2023-03-31 Thread Ni, Ray

Ard,
Thanks for the detailed commit messages. That really helps me to understand why 
XCODE version
was needed.

However, I feel it would be great if you can "highlight" what are changed by 
this patch.
The following is just an example. You can reword as you like.

1. Change for non-XCODE SecPeiCpuExceptionHandlerLib:
   * Use SecPeiExceptionHandlerAsm.nasm (renamed from ExceptionHandlerAsm.nasm)
   * Removed some unnecessary absolute references
   * (32 IDT stubs are still in .text.)
2. Change for XCODE SecPeiCpuExceptionHandlerLib:
   * Use SecPeiExceptionHandlerAsm.nasm instead of 
Xcode5ExceptionHandlerAsm.nasm
   * CET logic is not in SecPeiExceptionHandlerAsm.nasm (but aligns to 
non-XCODE lib instance)
   * Fixed a bug that does runtime fixup in TEXT section in SPI flash.
   * Emitted the code carrying the absolute symbol references into the .data 
which XCODE or
  LLD linkers allow.
 Then fixup can be done by other build tools such as GenFv if the code runs 
in SPI flash,
 or by PE coff loader if the code is loaded to memory.

Again, thanks for the quick patches just because I asked some XCODE questions.

Thanks,
Ray

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Friday, March 31, 2023 5:15 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Ni, Ray ; Andrew
> Fish ; Kinney, Michael D ;
> Liu, Zhiguang ; Rebecca Cran
> ; Tom Lendacky ;
> Marvin Häuser 
> Subject: [RFT PATCH v3 2/5] UefiCpuPkg/CpuExceptionHandlerLib: Use single
> SEC/PEI version
> 
> Currently, we use the non-Xcode5 version of ExceptionHandlerAsm.nasm
> only for the SEC and PEI phases, and this version was not compatible
> with the XCODE or LLD linkers, which do not permit absolute relocations
> in read-only sections.
> 
> Given that SEC and PEI code typically executes in place from flash and
> does not use page alignment for sections, we can simply emit the code
> carrying the absolute symbol references into the .data segment instead.
> This works around the linker's objections, and the resulting image will
> be mapped executable in its entirety anyway. Since this is only needed
> for XCODE, let's make this change conditionally using a preprocessor
> macro.
> 
> Let's rename the .nasm file to reflect the fact that is used for the
> SecPei flavor of this library only, and while at it, remove some
> unnecessary absolute references.
> 
> Also update the Xcode specific version of this library, and use this
> source file instead. This is necesessary, as the Xcode specific version
> modifies its own code at runtime, which is not permitted in SEC or PEI.
> Note that this also removes CET support from the Xcode5 specific build
> of the SEC/PEI version of this library, but this is not needed this
> early in any case, and this aligns it with other toolchains, which use
> this version of the library, which does not have CET support either.
> 
> Signed-off-by: Ard Biesheuvel 
> ---
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib
> .inf |  4 +++-
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/{ExceptionHandlerAsm.na
> sm => SecPeiExceptionHandlerAsm.nasm} | 12 
> 
> UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHa
> ndlerLib.inf   |  4 +++-
>  3 files changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandler
> Lib.inf
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandler
> Lib.inf
> index df44371fe018e06d..885bb6638ab58620 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandler
> Lib.inf
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandler
> Lib.inf
> @@ -28,7 +28,7 @@ [Sources.Ia32]
>Ia32/ArchInterruptDefs.h
> 
> 
> 
>  [Sources.X64]
> 
> -  X64/ExceptionHandlerAsm.nasm
> 
> +  X64/SecPeiExceptionHandlerAsm.nasm
> 
>X64/ArchExceptionHandler.c
> 
>X64/ArchInterruptDefs.h
> 
> 
> 
> @@ -58,3 +58,5 @@ [Pcd]
>  [FeaturePcd]
> 
>gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackGuard##
> CONSUMES
> 
> 
> 
> +[BuildOptions]
> 
> +  XCODE:*_*_X64_PP_FLAGS = -DNO_ABSOLUTE_RELOCS_IN_TEXT
> 
> diff --git
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.n
> asm
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/SecPeiExceptionHandler
> Asm.nasm
> similarity index 94%
> rename from
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nas
> m
> rename to
> UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/SecPeiExceptionHandlerA
> sm.nasm
> index aaf8d622e6f3b8f1..ec45c60181906c14 100644
> ---
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.n
> asm
> +++
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/SecPeiExceptionHandler
> Asm.nasm
> @@ -27,7 +27,9 @@ extern ASM_PFX(CommonExceptionHandler)
>  SECTION .data
> 
> 
> 
>  DEFAULT REL
> 
> +#ifndef NO_ABSOLUTE_RELOCS_IN_TEXT
> 
>  SECTION

Re: [edk2-devel] [Patch V2 0/8] Create page table by CpuPageTableLib in DxeIpl

2023-03-31 Thread duntan

Hi Tom,

Reccentlly I sent this patch set to change DxeIpl code to use CpuPageTableLib 
to create page table. I have done some test on Intel CPU to make sure that the 
page table created by DxeIpl before the change is the same as the page table 
created by DxeIpl after the change. But there was a remaining case that I 
didn't cover. The case is that PcdPteMemoryEncryptionAddressOrMask, PcdGhcbBase 
and PcdGhcbSize are not zero(when memory encryption is enabled on AMD 
processors supporting the SEV feature). 
So could you please help do a test on AMD processor to make sure that the SEV 
feature still works good with this pacth set?

Thanks, 
Dun

-Original Message-
From: devel@edk2.groups.io  On Behalf Of duntan
Sent: Friday, March 31, 2023 5:34 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] [Patch V2 0/8] Create page table by CpuPageTableLib in 
DxeIpl

In this V2 patch set:
1.Remove the unneeded patch for ArmVirtPkg 2.In this patch 'Create page table 
by CpuPageTableLib', change the input parameter name from Is32BitPageTable to 
Is64BitPageTable and add a line of "MapAttribute.Bits.Present = 0" before set a 
range to non-present.
3.In this patch 'Refinement to the code to set PageTable as RO', add a line of 
"MapAttribute.Bits.ReadWrite = 0" before set a range to ReadOnly.

Dun Tan (8):
  EmulatorPkg: Add CpuPageTableLib required by DxeIpl in DSC
  IntelFsp2Pkg: Add CpuPageTableLib required by DxeIpl in DSC
  MdeModulePkg: Add CpuPageTableLib required by DxeIpl in DSC
  OvmfPkg: Add CpuPageTableLib required by DxeIpl in DSC file
  MdeModulePkg: Add UefiCpuPkg.dec to pass DependencyCheck
  MdeModulePkg/DxeIpl: Create page table by CpuPageTableLib
  MdeModulePkg/DxeIpl: Remove duplicated code to enable NX
  MdeModulePkg/DxeIpl: Refinement to the code to set PageTable as RO

 EmulatorPkg/EmulatorPkg.dsc  |   3 ++-
 IntelFsp2Pkg/Tools/Tests/QemuFspPkg.dsc  |   3 ++-
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h|   3 ++-
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |   4 +++-
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  | 112 

 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |   5 +++--
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 711 
+++
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 182 
++
 MdeModulePkg/MdeModulePkg.ci.yaml|   5 +++--
 MdeModulePkg/MdeModulePkg.dsc|   3 ++-
 OvmfPkg/AmdSev/AmdSevX64.dsc |   2 +-
 OvmfPkg/Bhyve/BhyveX64.dsc   |   3 ++-
 OvmfPkg/CloudHv/CloudHvX64.dsc   |   2 +-
 OvmfPkg/Microvm/MicrovmX64.dsc   |   2 +-
 OvmfPkg/OvmfPkgIa32.dsc  |   3 ++-
 OvmfPkg/OvmfPkgIa32X64.dsc   |   2 +-
 OvmfPkg/OvmfPkgX64.dsc   |   2 +-
 OvmfPkg/OvmfXen.dsc  |   2 +-
 18 files changed, 200 insertions(+), 849 deletions(-)

--
2.31.1.windows.1








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

[edk2-devel] [Patch V2 8/8] MdeModulePkg/DxeIpl: Refinement to the code to set PageTable as RO

2023-03-31 Thread duntan

Code refinement to the code to set page table as RO in DxeIpl module.
Set all page table pools as ReadOnly by calling PageTableMap() in
CpuPageTableLib multiple times instead of searching each page table
pool address in page table layer by layer. Also, this commit solve
the issue that original SetPageTablePoolReadOnly() code in DxeIpl
doesn't handle the Level5Paging case.

Bugzila: https://bugzilla.tianocore.org/show_bug.cgi?id=4176
Signed-off-by: Dun Tan 
Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Ray Ni 
Cc: Jian J Wang 
---
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 155 
+++
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h |  15 ---
 2 files changed, 15 insertions(+), 155 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index ecdbd2ca24..a9edf4de32 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -330,154 +330,37 @@ CreateOrUpdatePageTable (
   ASSERT (PageTableBufferSize == 0);
 }
 
-/**
-  Set one page of page table pool memory to be read-only.
-
-  @param[in] PageTableBaseBase address of page table (CR3).
-  @param[in] Address  Start address of a page to be set as read-only.
-  @param[in] Level4Paging Level 4 paging flag.
-
-**/
-VOID
-SetPageTablePoolReadOnly (
-  IN  UINTN PageTableBase,
-  IN  EFI_PHYSICAL_ADDRESS  Address,
-  IN  BOOLEAN   Level4Paging
-  )
-{
-  UINTN Index;
-  UINTN EntryIndex;
-  UINT64AddressEncMask;
-  EFI_PHYSICAL_ADDRESS  PhysicalAddress;
-  UINT64*PageTable;
-  UINT64*NewPageTable;
-  UINT64PageAttr;
-  UINT64LevelSize[5];
-  UINT64LevelMask[5];
-  UINTN LevelShift[5];
-  UINTN Level;
-  UINT64PoolUnitSize;
-
-  ASSERT (PageTableBase != 0);
-
-  //
-  // Since the page table is always from page table pool, which is always
-  // located at the boundary of PcdPageTablePoolAlignment, we just need to
-  // set the whole pool unit to be read-only.
-  //
-  Address = Address & PAGE_TABLE_POOL_ALIGN_MASK;
-
-  LevelShift[1] = PAGING_L1_ADDRESS_SHIFT;
-  LevelShift[2] = PAGING_L2_ADDRESS_SHIFT;
-  LevelShift[3] = PAGING_L3_ADDRESS_SHIFT;
-  LevelShift[4] = PAGING_L4_ADDRESS_SHIFT;
-
-  LevelMask[1] = PAGING_4K_ADDRESS_MASK_64;
-  LevelMask[2] = PAGING_2M_ADDRESS_MASK_64;
-  LevelMask[3] = PAGING_1G_ADDRESS_MASK_64;
-  LevelMask[4] = PAGING_1G_ADDRESS_MASK_64;
-
-  LevelSize[1] = SIZE_4KB;
-  LevelSize[2] = SIZE_2MB;
-  LevelSize[3] = SIZE_1GB;
-  LevelSize[4] = SIZE_512GB;
-
-  AddressEncMask = PcdGet64 (PcdPteMemoryEncryptionAddressOrMask) &
-   PAGING_1G_ADDRESS_MASK_64;
-  PageTable= (UINT64 *)(UINTN)PageTableBase;
-  PoolUnitSize = PAGE_TABLE_POOL_UNIT_SIZE;
-
-  for (Level = (Level4Paging) ? 4 : 3; Level > 0; --Level) {
-Index  = ((UINTN)RShiftU64 (Address, LevelShift[Level]));
-Index &= PAGING_PAE_INDEX_MASK;
-
-PageAttr = PageTable[Index];
-if ((PageAttr & IA32_PG_PS) == 0) {
-  //
-  // Go to next level of table.
-  //
-  PageTable = (UINT64 *)(UINTN)(PageAttr & ~AddressEncMask &
-PAGING_4K_ADDRESS_MASK_64);
-  continue;
-}
-
-if (PoolUnitSize >= LevelSize[Level]) {
-  //
-  // Clear R/W bit if current page granularity is not larger than pool unit
-  // size.
-  //
-  if ((PageAttr & IA32_PG_RW) != 0) {
-while (PoolUnitSize > 0) {
-  //
-  // PAGE_TABLE_POOL_UNIT_SIZE and PAGE_TABLE_POOL_ALIGNMENT are fit in
-  // one page (2MB). Then we don't need to update attributes for pages
-  // crossing page directory. ASSERT below is for that purpose.
-  //
-  ASSERT (Index < EFI_PAGE_SIZE/sizeof (UINT64));
-
-  PageTable[Index] &= ~(UINT64)IA32_PG_RW;
-  PoolUnitSize -= LevelSize[Level];
-
-  ++Index;
-}
-  }
-
-  break;
-} else {
-  //
-  // The smaller granularity of page must be needed.
-  //
-  ASSERT (Level > 1);
-
-  NewPageTable = AllocatePageTableMemory (1);
-  ASSERT (NewPageTable != NULL);
-
-  PhysicalAddress = PageAttr & LevelMask[Level];
-  for (EntryIndex = 0;
-   EntryIndex < EFI_PAGE_SIZE/sizeof (UINT64);
-   ++EntryIndex)
-  {
-NewPageTable[EntryIndex] = PhysicalAddress  | AddressEncMask |
-   IA32_PG_P | IA32_PG_RW;
-if (Level > 2) {
-  NewPageTable[EntryIndex] |= IA32_PG_PS;
-}
-
-PhysicalAddress += LevelSize[Level - 1];
-  }
-
-  PageTable[Index] = (UINT64)(UINTN)NewPageTable |

[edk2-devel] [Patch V2 6/8] MdeModulePkg/DxeIpl: Create page table by CpuPageTableLib

2023-03-31 Thread duntan

Modify CreateIdentityMappingPageTables() to create page table
based on CpuPageTableLib in DxeIpl module. This function can
be used to create both IA32 PAE paging and long mode 4-level,
5-level paging structure. With the PageTableMap() API in the
CpuPageTableLib, we can remove the complicated page table
manipulating code. This commit doesn't change any functionality.

Signed-off-by: Dun Tan 
Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Ray Ni 
Cc: Jian J Wang 
---
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h|   3 ++-
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |   4 +++-
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  | 109 
-
 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |   5 +++--
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 558 
+-
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 167 
++-
 6 files changed, 167 insertions(+), 679 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
index 2f015befce..03e6f8cff7 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
@@ -2,7 +2,7 @@
   Master header file for DxeIpl PEIM. All source files in this module should
   include this file for common definitions.
 
-Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.
 SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -42,6 +42,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 #include 
 #include 
 #include 
+#include 
 
 #define STACK_SIZE  0x2
 #define BSP_STORE_SIZE  0x4000
diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
index 052ea0ec1a..60623b4f66 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
@@ -5,7 +5,7 @@
 #  PPI to discover and dispatch the DXE Foundation and components that are
 #  needed to run the DXE Foundation.
 #
-#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.
 #  Copyright (c) 2017, AMD Incorporated. All rights reserved.
 #  Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
reserved.
 #  Copyright (c) 2022, Loongson Technology Corporation Limited. All rights 
reserved.
@@ -60,6 +60,7 @@
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
+  UefiCpuPkg/UefiCpuPkg.dec
 
 [Packages.ARM, Packages.AARCH64]
   ArmPkg/ArmPkg.dec
@@ -79,6 +80,7 @@
   DebugAgentLib
   PeiServicesTablePointerLib
   PerformanceLib
+  CpuPageTableLib
 
 [LibraryClasses.ARM, LibraryClasses.AARCH64]
   ArmMmuLib
diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c 
b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
index fdeaaa39d8..af1e1e3d02 100644
--- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
+++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
@@ -1,7 +1,7 @@
 /** @file
   Ia32-specific functionality for DxeLoad.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.
 Copyright (c) 2017, AMD Incorporated. All rights reserved.
 
 SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -70,107 +70,6 @@ GLOBAL_REMOVE_IF_UNREFERENCED  IA32_DESCRIPTOR  
gLidtDescriptor = {
   0
 };
 
-/**
-  Allocates and fills in the Page Directory and Page Table Entries to
-  establish a 4G page table.
-
-  @param[in] StackBase  Stack base address.
-  @param[in] StackSize  Stack size.
-
-  @return The address of page table.
-
-**/
-UINTN
-Create4GPageTablesIa32Pae (
-  IN EFI_PHYSICAL_ADDRESS  StackBase,
-  IN UINTN StackSize
-  )
-{
-  UINT8   PhysicalAddressBits;
-  EFI_PHYSICAL_ADDRESSPhysicalAddress;
-  UINTN   IndexOfPdpEntries;
-  UINTN   IndexOfPageDirectoryEntries;
-  UINT32  NumberOfPdpEntriesNeeded;
-  PAGE_MAP_AND_DIRECTORY_POINTER  *PageMap;
-  PAGE_MAP_AND_DIRECTORY_POINTER  *PageDirectoryPointerEntry;
-  PAGE_TABLE_ENTRY*PageDirectoryEntry;
-  UINTN

[edk2-devel] [Patch V2 7/8] MdeModulePkg/DxeIpl: Remove duplicated code to enable NX

2023-03-31 Thread duntan

In IA32 code, remove the duplicated code to enable NX.
In the previous patch, IA32 code also uses the new
CreateIdentityMappingPageTables() to create PAE page table.
This function calls EnableExecuteDisableBit if needed.

Signed-off-by: Dun Tan 
Cc: Dandan Bi 
Cc: Liming Gao 
Reviewed-by: Ray Ni 
Cc: Jian J Wang 
---
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c 
b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
index af1e1e3d02..83c5478895 100644
--- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
+++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
@@ -322,9 +322,6 @@ HandOffToDxeCore (
 BuildPageTablesIa32Pae = ToBuildPageTable ();
 if (BuildPageTablesIa32Pae) {
   PageTables = CreateIdentityMappingPageTables (FALSE, BaseOfStack, 
STACK_SIZE, 0, 0);
-  if (IsEnableNonExecNeeded ()) {
-EnableExecuteDisableBit ();
-  }
 }
 
 //
-- 
2.31.1.windows.1



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

[edk2-devel] [Patch V2 5/8] MdeModulePkg: Add UefiCpuPkg.dec to pass DependencyCheck

2023-03-31 Thread duntan

Add UefiCpuPkg/UefiCpuPkg.dec in MdeModulePkg.ci.yaml to pass
DependencyCheck since DxeIpl in MdeModulePkg needs to consume
CpuPageTableLib in UefiCpuPkg.

Signed-off-by: Dun Tan 
Cc: Liming Gao 
Cc: Ray Ni 
Cc: Jian J Wang 
---
 MdeModulePkg/MdeModulePkg.ci.yaml | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.ci.yaml 
b/MdeModulePkg/MdeModulePkg.ci.yaml
index f69989087b..d2616f4cdc 100644
--- a/MdeModulePkg/MdeModulePkg.ci.yaml
+++ b/MdeModulePkg/MdeModulePkg.ci.yaml
@@ -2,7 +2,7 @@
 # CI configuration for MdeModulePkg
 #
 # Copyright (c) Microsoft Corporation
-# Copyright (c) 2020, Intel Corporation. All rights reserved.
+# Copyright (c) 2020 - 2023, Intel Corporation. All rights reserved.
 # (C) Copyright 2021 Hewlett Packard Enterprise Development LP
 # SPDX-License-Identifier: BSD-2-Clause-Patent
 ##
@@ -51,7 +51,8 @@
 "MdePkg/MdePkg.dec",
 "MdeModulePkg/MdeModulePkg.dec",
 "StandaloneMmPkg/StandaloneMmPkg.dec",
-"ArmPkg/ArmPkg.dec"  # this should be fixed by promoting an 
abstraction
+"ArmPkg/ArmPkg.dec",  # this should be fixed by promoting an 
abstraction
+"UefiCpuPkg/UefiCpuPkg.dec"
 ],
 # For host based unit tests
 "AcceptableDependencies-HOST_APPLICATION":[
-- 
2.31.1.windows.1



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

[edk2-devel] [Patch V2 4/8] OvmfPkg: Add CpuPageTableLib required by DxeIpl in DSC file

2023-03-31 Thread duntan

Add CpuPageTableLib instance required by DxeIpl in corresponding
DSC files of OvmfPkg.

Signed-off-by: Dun Tan 
Cc: Ard Biesheuvel 
Cc: Jiewen Yao 
Cc: Jordan Justen 
Cc: Gerd Hoffmann 
Cc: Ray Ni 
---
 OvmfPkg/AmdSev/AmdSevX64.dsc   | 2 +-
 OvmfPkg/Bhyve/BhyveX64.dsc | 3 ++-
 OvmfPkg/CloudHv/CloudHvX64.dsc | 2 +-
 OvmfPkg/Microvm/MicrovmX64.dsc | 2 +-
 OvmfPkg/OvmfPkgIa32.dsc| 3 ++-
 OvmfPkg/OvmfPkgIa32X64.dsc | 2 +-
 OvmfPkg/OvmfPkgX64.dsc | 2 +-
 OvmfPkg/OvmfXen.dsc| 2 +-
 8 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index c005e474dd..3a23e38263 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -169,6 +169,7 @@
   
MemEncryptTdxLib|OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf
   PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
   DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
+  CpuPageTableLib|UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableLib.inf
 
 !if $(SOURCE_DEBUG_ENABLE) == TRUE
   
PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf
@@ -352,7 +353,6 @@
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
 !endif
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
-  CpuPageTableLib|UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableLib.inf
   MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
   
NestedInterruptTplLib|OvmfPkg/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
diff --git a/OvmfPkg/Bhyve/BhyveX64.dsc b/OvmfPkg/Bhyve/BhyveX64.dsc
index d0d2712c56..67f8a77c3a 100644
--- a/OvmfPkg/Bhyve/BhyveX64.dsc
+++ b/OvmfPkg/Bhyve/BhyveX64.dsc
@@ -1,6 +1,6 @@
 #
 #  Copyright (c) 2020, Rebecca Cran 
-#  Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.
 #  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 #  Copyright (c) 2014, Pluribus Networks, Inc.
 #
@@ -171,6 +171,7 @@
   
MemEncryptTdxLib|OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf
   PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
   DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
+  CpuPageTableLib|UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableLib.inf
 
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index b9820cc14b..ffc65b0e15 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -190,6 +190,7 @@
   MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/DxeMemEncryptSevLib.inf
   PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
   DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
+  CpuPageTableLib|UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableLib.inf
 !if $(SMM_REQUIRE) == FALSE
   LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxBaseLib.inf
 !endif
@@ -403,7 +404,6 @@
   DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf
 !endif
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
-  CpuPageTableLib|UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableLib.inf
   MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
   
NestedInterruptTplLib|OvmfPkg/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 384b0b7afc..aa74a9d5ad 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -193,6 +193,7 @@
   
MemEncryptTdxLib|OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf
   PeiHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/PeiHardwareInfoLib.inf
   DxeHardwareInfoLib|OvmfPkg/Library/HardwareInfoLib/DxeHardwareInfoLib.inf
+  CpuPageTableLib|UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableLib.inf
 
 !if $(SOURCE_DEBUG_ENABLE) == TRUE
   
PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf
@@ -402,7 +403,6 @@
   PciLib|MdePkg/Library/BasePciLibPciExpress/BasePciLibPciExpress.inf
   PciPcdProducerLib|OvmfPkg/Fdt/FdtPciPcdProducerLib/FdtPciPcdProducerLib.inf
   
PciExpressLib|OvmfPkg/Library/BaseCachingPciExpressLib/BaseCachingPciExpressLib.inf
-  CpuPageTableLib|UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableLib.inf
   MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
   
NestedInterruptTplLib|OvmfPkg/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf

[edk2-devel] [Patch V2 2/8] IntelFsp2Pkg: Add CpuPageTableLib required by DxeIpl in DSC

2023-03-31 Thread duntan

Add CpuPageTableLib instance required by DxeIpl in QemuFspPkg.dsc
of IntelFsp2Pkg.

Signed-off-by: Dun Tan 
Reviewed-by: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Star Zeng 
Cc: Ray Ni 
---
 IntelFsp2Pkg/Tools/Tests/QemuFspPkg.dsc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/IntelFsp2Pkg/Tools/Tests/QemuFspPkg.dsc 
b/IntelFsp2Pkg/Tools/Tests/QemuFspPkg.dsc
index 3155812118..52052692dd 100644
--- a/IntelFsp2Pkg/Tools/Tests/QemuFspPkg.dsc
+++ b/IntelFsp2Pkg/Tools/Tests/QemuFspPkg.dsc
@@ -1,7 +1,7 @@
 ## @file
 # FSP DSC build file for QEMU platform
 #
-# Copyright (c) 2017 - 2021, Intel Corporation. All rights reserved.
+# Copyright (c) 2017 - 2023, Intel Corporation. All rights reserved.
 #
 #This program and the accompanying materials
 #are licensed and made available under the terms and conditions of the BSD 
License
@@ -114,6 +114,7 @@
   DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
   SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf
 !endif
+  CpuPageTableLib|UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableLib.inf
 
 
 

-- 
2.31.1.windows.1



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

[edk2-devel] [Patch V2 3/8] MdeModulePkg: Add CpuPageTableLib required by DxeIpl in DSC

2023-03-31 Thread duntan

Add CpuPageTableLib instance required by DxeIpl in
MdeModulePkg.dsc.

Signed-off-by: Dun Tan 
Cc: Jian J Wang 
Cc: Liming Gao 
Cc: Ray Ni 
---
 MdeModulePkg/MdeModulePkg.dsc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 1014598f31..d95acabe83 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -2,7 +2,7 @@
 # EFI/PI Reference Module Package for All Architectures
 #
 # (C) Copyright 2014 Hewlett-Packard Development Company, L.P.
-# Copyright (c) 2007 - 2021, Intel Corporation. All rights reserved.
+# Copyright (c) 2007 - 2023, Intel Corporation. All rights reserved.
 # Copyright (c) Microsoft Corporation.
 # Copyright (C) 2023 Advanced Micro Devices, Inc. All rights reserved.
 #
@@ -106,6 +106,7 @@
   
MmUnblockMemoryLib|MdePkg/Library/MmUnblockMemoryLib/MmUnblockMemoryLibNull.inf
   
VariableFlashInfoLib|MdeModulePkg/Library/BaseVariableFlashInfoLib/BaseVariableFlashInfoLib.inf
   
IpmiCommandLib|MdeModulePkg/Library/BaseIpmiCommandLibNull/BaseIpmiCommandLibNull.inf
+  CpuPageTableLib|UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableLib.inf
 
 [LibraryClasses.EBC.PEIM]
   IoLib|MdePkg/Library/PeiIoLibCpuIo/PeiIoLibCpuIo.inf
-- 
2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102268): https://edk2.groups.io/g/devel/message/102268
Mute This Topic: https://groups.io/mt/97969854/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/8] Create page table by CpuPageTableLib in DxeIpl

2023-03-31 Thread duntan

In this V2 patch set:
1.Remove the unneeded patch for ArmVirtPkg
2.In this patch 'Create page table by CpuPageTableLib', change the input 
parameter name from Is32BitPageTable to Is64BitPageTable and add a line of 
"MapAttribute.Bits.Present = 0" before set a range to non-present.
3.In this patch 'Refinement to the code to set PageTable as RO', add a line of 
"MapAttribute.Bits.ReadWrite = 0" before set a range to ReadOnly.

Dun Tan (8):
  EmulatorPkg: Add CpuPageTableLib required by DxeIpl in DSC
  IntelFsp2Pkg: Add CpuPageTableLib required by DxeIpl in DSC
  MdeModulePkg: Add CpuPageTableLib required by DxeIpl in DSC
  OvmfPkg: Add CpuPageTableLib required by DxeIpl in DSC file
  MdeModulePkg: Add UefiCpuPkg.dec to pass DependencyCheck
  MdeModulePkg/DxeIpl: Create page table by CpuPageTableLib
  MdeModulePkg/DxeIpl: Remove duplicated code to enable NX
  MdeModulePkg/DxeIpl: Refinement to the code to set PageTable as RO

 EmulatorPkg/EmulatorPkg.dsc  |   3 ++-
 IntelFsp2Pkg/Tools/Tests/QemuFspPkg.dsc  |   3 ++-
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h|   3 ++-
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |   4 +++-
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  | 112 

 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |   5 +++--
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 711 
+++
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 182 
++
 MdeModulePkg/MdeModulePkg.ci.yaml|   5 +++--
 MdeModulePkg/MdeModulePkg.dsc|   3 ++-
 OvmfPkg/AmdSev/AmdSevX64.dsc |   2 +-
 OvmfPkg/Bhyve/BhyveX64.dsc   |   3 ++-
 OvmfPkg/CloudHv/CloudHvX64.dsc   |   2 +-
 OvmfPkg/Microvm/MicrovmX64.dsc   |   2 +-
 OvmfPkg/OvmfPkgIa32.dsc  |   3 ++-
 OvmfPkg/OvmfPkgIa32X64.dsc   |   2 +-
 OvmfPkg/OvmfPkgX64.dsc   |   2 +-
 OvmfPkg/OvmfXen.dsc  |   2 +-
 18 files changed, 200 insertions(+), 849 deletions(-)

-- 
2.31.1.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102265): https://edk2.groups.io/g/devel/message/102265
Mute This Topic: https://groups.io/mt/97969850/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/8] EmulatorPkg: Add CpuPageTableLib required by DxeIpl in DSC

2023-03-31 Thread duntan

Add CpuPageTableLib instance required by DxeIpl in EmulatorPkg.dsc.

Signed-off-by: Dun Tan 
Cc: Andrew Fish 
Cc: Ray Ni 
---
 EmulatorPkg/EmulatorPkg.dsc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/EmulatorPkg/EmulatorPkg.dsc b/EmulatorPkg/EmulatorPkg.dsc
index b44435d7e6..d1fb9d9256 100644
--- a/EmulatorPkg/EmulatorPkg.dsc
+++ b/EmulatorPkg/EmulatorPkg.dsc
@@ -4,7 +4,7 @@
 # The Emulation Platform can be used to debug individual modules, prior to 
creating
 # a real platform. This also provides an example for how an DSC is created.
 #
-# Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
+# Copyright (c) 2006 - 2023, Intel Corporation. All rights reserved.
 # Portions copyright (c) 2010 - 2011, Apple Inc. All rights reserved.
 # Copyright (c) Microsoft Corporation.
 #
@@ -66,6 +66,7 @@
   
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
   
FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf
+  CpuPageTableLib|UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableLib.inf
 
   #
   # UEFI & PI
-- 
2.31.1.windows.1



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

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

2023-03-31 Thread Ard Biesheuvel

On Fri, 31 Mar 2023 at 11:27, Marvin Häuser  wrote:
>
>
> > On 31. Mar 2023, at 10:59, Ard Biesheuvel  wrote:
> >
> > On Fri, 31 Mar 2023 at 10:29, Marvin Häuser  wrote:
> >>
> >>
>  On 31. Mar 2023, at 09:39, Ard Biesheuvel  wrote:
> >>> Hi Marvin,
> >>>
> >>> Thanks for the context.
> >>>
> >>>
> >>> On Thu, 30 Mar 2023 at 23:54, Marvin Häuser  wrote:
> 
>  Hi Ard,
> 
>  Sorry, I cannot preserve the CC list as the groups.io interface doesn't 
>  seem to allow it. Can you please CC me on future revisions?
> 
>  This patch will badly corrupt binaries. I cannot cite a source right now 
>  (if you want me to, please remind me in your response, so I can look it 
>  up tomorrow), but for X64 (but not IA32, which is why this is enabled 
>  there), relocs are relative to the first *writable* segment. In other 
>  words, any relocation to __TEXT will badly corrupt binaries this way.
> >>>
> >>> OMG.
> >>>
> >>> I can't believe how buggy all this stuff is. But I can confirm that
> >>> the resulting binaries don't look right, even though they appear to
> >>> boot fine.
> >>
> >> Codegen does not change from the suppress flag, so there will be no 
> >> additional text relocs beyond those you introduced. As they target the 
> >> exception handler, I guess you’d need to actively provoke the broken code 
> >> paths (and may end up with a nice recursion :) ).
> >>
> >
> > I understand that the codegen is the same. I was specifically talking
> > about the PE relocations, which seem to be lacking entirely.
>
> Sure, I was just elaborating on the “appear to boot fine” part, which does 
> make sense. When I last tried, the relocs were not absent but underflown. 
> Might be mtoc drops them somehow, I think I inspected the Mach-O directly. 
> Whatever, you reproduce the issue. :)
>

Fair enough.

> >
> >>> In particular, when I dump the PE relocations using
> >>> llvm-readobj --coff-basereloc, I don't see any relocations referring
> >>> to the .text section.
> >>>
>  In AUDK, we support this with two essential changes. The first is that 
>  we always generate a writable dummy segment at the beginning of the 
>  address space [1], making the relocs relative to the image base. The 
>  second is that in ocmtoc, our fork of the abandoned (and pretty 
>  badly-bugged) Apple mtoc, we explicitly require this segment to be 
>  present and verify its virtual address is the minimum virtual address 
>  [2]. It is then omitted from the conversion process [3]. I suggest you 
>  replicate these changes and fully switch to ocmtoc for XCODE5 builds.
> >>>
> >>> I'm not going to do any of that. Instead, I am going to drop this
> >>> change, and do the following:
> >>>
> >>> - modify the SecPei version of CpuExceptionHandlerLib to put the
> >>> vector templates in .data, as I proposed before. This works around the
> >>> issue, and given that SEC/PEI is assumed to be read-only anyway (as it
> >>> may execute in place from flash) and does not use page alignment for
> >>> the sections due to size constraints, it is reasonable to assume that
> >>> .text and .data will be mapped executable anyway.
> >>
> >> Well, that assumption is more than fair to make for the status quo 
> >> platforms, but this is just another rock in the way of doing things the 
> >> right way (even if it’s just VMs).
> >>
> >
> > How so? SEC and PEI could be mapped read-only today, it's just that we
> > never bother.
>
> I’m not concerned about read-only but NX.
>

We don't have writable data in SEC or PEI, so this would require SEC,
PEI_CORE and every PEIM to have split .text and .rodata, and round
them up to page size. Not sure this is worth it, especially given the
fact that CoCo targets seems to be skipping the PEI phase entirely.

> >
> >> Cc Gerd for an OVMF security perspective. Is PEI-time memory protection 
> >> something you’d be interested in in the future?
> >>
> >
> > My WXN series for ARM maps all PEIMs read-only, and turns off
> > shadowing entirely (which makes no sense for VMs). So we have most of
> > what we need to do that, and this change has no bearing on that.
>
> Well yes, if everything is read-only, you guarantee W^X implicitly, but 
> downstream we have plans for the full deal including NX data. It’s however 
> shelved for the distant future, so as long as this is changed with the 
> intention of reverting it once XCODE5 is fixed or dropped, that sounds fine 
> to me. I just don’t like the notion of intentionally breaking the memory 
> permission model as a hack. I rather hope we’ll make some swift progress on 
> removing XCODE5 as a source of frustration. :)
>

Pardon my bluntness, but why should I care about the shelved future
plans of some downstream project?

> >
> >>>
> >>> - update the version that performs the runtime fixups to only do so
> >>> when using the XCODE toolchain - we can phase that out once we drop
> >>> XCODE support.
> >>
> >> I agree if there’s an

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

2023-03-31 Thread Marvin Häuser



> On 31. Mar 2023, at 10:59, Ard Biesheuvel  wrote:
> 
> On Fri, 31 Mar 2023 at 10:29, Marvin Häuser  wrote:
>> 
>> 
 On 31. Mar 2023, at 09:39, Ard Biesheuvel  wrote:
>>> Hi Marvin,
>>> 
>>> Thanks for the context.
>>> 
>>> 
>>> On Thu, 30 Mar 2023 at 23:54, Marvin Häuser  wrote:
 
 Hi Ard,
 
 Sorry, I cannot preserve the CC list as the groups.io interface doesn't 
 seem to allow it. Can you please CC me on future revisions?
 
 This patch will badly corrupt binaries. I cannot cite a source right now 
 (if you want me to, please remind me in your response, so I can look it up 
 tomorrow), but for X64 (but not IA32, which is why this is enabled there), 
 relocs are relative to the first *writable* segment. In other words, any 
 relocation to __TEXT will badly corrupt binaries this way.
>>> 
>>> OMG.
>>> 
>>> I can't believe how buggy all this stuff is. But I can confirm that
>>> the resulting binaries don't look right, even though they appear to
>>> boot fine.
>> 
>> Codegen does not change from the suppress flag, so there will be no 
>> additional text relocs beyond those you introduced. As they target the 
>> exception handler, I guess you’d need to actively provoke the broken code 
>> paths (and may end up with a nice recursion :) ).
>> 
> 
> I understand that the codegen is the same. I was specifically talking
> about the PE relocations, which seem to be lacking entirely.

Sure, I was just elaborating on the “appear to boot fine” part, which does make 
sense. When I last tried, the relocs were not absent but underflown. Might be 
mtoc drops them somehow, I think I inspected the Mach-O directly. Whatever, you 
reproduce the issue. :)

> 
>>> In particular, when I dump the PE relocations using
>>> llvm-readobj --coff-basereloc, I don't see any relocations referring
>>> to the .text section.
>>> 
 In AUDK, we support this with two essential changes. The first is that we 
 always generate a writable dummy segment at the beginning of the address 
 space [1], making the relocs relative to the image base. The second is 
 that in ocmtoc, our fork of the abandoned (and pretty badly-bugged) Apple 
 mtoc, we explicitly require this segment to be present and verify its 
 virtual address is the minimum virtual address [2]. It is then omitted 
 from the conversion process [3]. I suggest you replicate these changes and 
 fully switch to ocmtoc for XCODE5 builds.
>>> 
>>> I'm not going to do any of that. Instead, I am going to drop this
>>> change, and do the following:
>>> 
>>> - modify the SecPei version of CpuExceptionHandlerLib to put the
>>> vector templates in .data, as I proposed before. This works around the
>>> issue, and given that SEC/PEI is assumed to be read-only anyway (as it
>>> may execute in place from flash) and does not use page alignment for
>>> the sections due to size constraints, it is reasonable to assume that
>>> .text and .data will be mapped executable anyway.
>> 
>> Well, that assumption is more than fair to make for the status quo 
>> platforms, but this is just another rock in the way of doing things the 
>> right way (even if it’s just VMs).
>> 
> 
> How so? SEC and PEI could be mapped read-only today, it's just that we
> never bother.

I’m not concerned about read-only but NX.

> 
>> Cc Gerd for an OVMF security perspective. Is PEI-time memory protection 
>> something you’d be interested in in the future?
>> 
> 
> My WXN series for ARM maps all PEIMs read-only, and turns off
> shadowing entirely (which makes no sense for VMs). So we have most of
> what we need to do that, and this change has no bearing on that.

Well yes, if everything is read-only, you guarantee W^X implicitly, but 
downstream we have plans for the full deal including NX data. It’s however 
shelved for the distant future, so as long as this is changed with the 
intention of reverting it once XCODE5 is fixed or dropped, that sounds fine to 
me. I just don’t like the notion of intentionally breaking the memory 
permission model as a hack. I rather hope we’ll make some swift progress on 
removing XCODE5 as a source of frustration. :)

> 
>>> 
>>> - update the version that performs the runtime fixups to only do so
>>> when using the XCODE toolchain - we can phase that out once we drop
>>> XCODE support.
>> 
>> I agree if there’s an actual plan on doing that. We depend on XCODE5 
>> downstream, but I think it would literally be easier for us if the upstream 
>> version was dropped than rebasing against hacks that our slightly modded 
>> variant does not require.
>> 
>> Cc Andrew and Rebecca. I don’t know anyone else who might still be using 
>> XCODE5. Any objections to dropping it? If so, any plans to pick up my 
>> proposed changes instead?
>> 
> 
> I wouldn't mind dropping it. In fact, I'm wondering - given that you
> need to install nasm and iasl anyway - if it wouldn't make more sense
> to use the CLANGPDB toolchain on macOS, and avoid

Re: [edk2-devel] [PATCH 0/6] Substract TME-MK KEY_ID_BITS from CPU max PA

2023-03-31 Thread Gerd Hoffmann

On Fri, Mar 31, 2023 at 08:02:00AM +, Ni, Ray wrote:
> Gerd,
> Can you give a Reviewed-by/Acked-by for the patch series?

> > This Bugzilla captures the same idea:
> > https://bugzilla.tianocore.org/show_bug.cgi?id=3394

Oh, the bug lists even more places which care about
the physical address width.

Sure you want merge the series in this apparently
incomplete state?

It should have no bad effects on OVMF though, so if you
prefer to merge this as-is and implement the suggested
library solution as separate patch series:

Acked-by: Gerd Hoffmann 

take care,
  Gerd



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

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

2023-03-31 Thread Gerd Hoffmann

  Hi,

> > - modify the SecPei version of CpuExceptionHandlerLib to put the
> > vector templates in .data, as I proposed before. This works around the
> > issue, and given that SEC/PEI is assumed to be read-only anyway (as it
> > may execute in place from flash) and does not use page alignment for
> > the sections due to size constraints, it is reasonable to assume that
> > .text and .data will be mapped executable anyway.
> 
> Well, that assumption is more than fair to make for the status quo
> platforms, but this is just another rock in the way of doing things
> the right way (even if it’s just VMs).
> 
> Cc Gerd for an OVMF security perspective. Is PEI-time memory
> protection something you’d be interested in in the future?

Given that PEI is expected to be able to run from read-only storage
the easiest way to apply X^W rules would be to just map the whole
PEI firmware volume as R-X when executing from RAM (which is the case
for OVMF).

I've fixed OVMF PEI modules last year to *not* use global variables,
so OVMF is not a special case any more and mapping OVMF PEI readonly
should work just fine.

So Ard's approach looks sane to me.

take care,
  Gerd



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

[edk2-devel] [RFT PATCH v3 5/5] UefiCpuPkg/CpuExceptionHandlerLib: Drop special XCODE5 version

2023-03-31 Thread Ard Biesheuvel

This library is no longer used or needed, so let's remove it.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Ray Ni 
---
 
UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
 | 67 
 
UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.uni
 | 18 --
 UefiCpuPkg/UefiCpuPkg.dsc  
  |  7 --
 3 files changed, 92 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
deleted file mode 100644
index 17f872bb15eb0ff7..
--- 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
+++ /dev/null
@@ -1,67 +0,0 @@
-## @file
-#  CPU Exception Handler library instance for SEC/PEI modules.
-#
-#  Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.
-#  Copyright (c) 2012 - 2022, Intel Corporation. All rights reserved.
-#  SPDX-License-Identifier: BSD-2-Clause-Patent
-#
-#  This is the XCODE5 variant of the SEC/PEI CpuExceptionHandlerLib. This
-#  variant performs binary patching to fix up addresses that allow the
-#  XCODE5 toolchain to be used.
-#
-##
-
-[Defines]
-  INF_VERSION= 0x00010005
-  BASE_NAME  = Xcode5SecPeiCpuExceptionHandlerLib
-  MODULE_UNI_FILE= Xcode5SecPeiCpuExceptionHandlerLib.uni
-  FILE_GUID  = 49C481AF-1621-42F3-8FA1-27C64143E304
-  MODULE_TYPE= PEIM
-  VERSION_STRING = 1.1
-  LIBRARY_CLASS  = CpuExceptionHandlerLib|SEC PEI_CORE PEIM
-
-#
-# The following information is for reference only and not required by the 
build tools.
-#
-#  VALID_ARCHITECTURES   = IA32 X64
-#
-
-[Sources.Ia32]
-  Ia32/ExceptionHandlerAsm.nasm
-  Ia32/ExceptionTssEntryAsm.nasm
-  Ia32/ArchExceptionHandler.c
-  Ia32/ArchInterruptDefs.h
-
-[Sources.X64]
-  X64/SecPeiExceptionHandlerAsm.nasm
-  X64/ArchExceptionHandler.c
-  X64/ArchInterruptDefs.h
-
-[Sources.common]
-  CpuExceptionCommon.h
-  CpuExceptionCommon.c
-  SecPeiCpuException.c
-
-[Packages]
-  MdePkg/MdePkg.dec
-  MdeModulePkg/MdeModulePkg.dec
-  UefiCpuPkg/UefiCpuPkg.dec
-
-[LibraryClasses]
-  BaseLib
-  SerialPortLib
-  PrintLib
-  LocalApicLib
-  PeCoffGetEntryPointLib
-  CcExitLib
-
-[Pcd]
-  gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard
-  gUefiCpuPkgTokenSpaceGuid.PcdCpuStackSwitchExceptionList
-  gUefiCpuPkgTokenSpaceGuid.PcdCpuKnownGoodStackSize
-
-[FeaturePcd]
-  gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackGuard## CONSUMES
-
-[BuildOptions]
-  XCODE:*_*_X64_PP_FLAGS = -DNO_ABSOLUTE_RELOCS_IN_TEXT
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.uni
 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.uni
deleted file mode 100644
index a63b25f39d992775..
--- 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.uni
+++ /dev/null
@@ -1,18 +0,0 @@
-// /** @file
-// XCODE5 CPU Exception Handler library instance for SEC/PEI modules.
-//
-// CPU Exception Handler library instance for SEC/PEI modules when built
-// using the XCODE5 toolchain.
-//
-// Copyright (C) 2020, Advanced Micro Devices, Inc. All rights reserved.
-// Copyright (c) 2012 - 2014, Intel Corporation. All rights reserved.
-//
-// SPDX-License-Identifier: BSD-2-Clause-Patent
-//
-// **/
-
-
-#string STR_MODULE_ABSTRACT #language en-US "CPU Exception Handler 
library instance for SEC/PEI modules with the XCODE5 toolchain."
-
-#string STR_MODULE_DESCRIPTION  #language en-US "CPU Exception Handler 
library instance for SEC/PEI modules with the XCODE5 toolchain."
-
diff --git a/UefiCpuPkg/UefiCpuPkg.dsc b/UefiCpuPkg/UefiCpuPkg.dsc
index a7318d3fe9db0ec4..d85d56916f2cdbce 100644
--- a/UefiCpuPkg/UefiCpuPkg.dsc
+++ b/UefiCpuPkg/UefiCpuPkg.dsc
@@ -69,11 +69,7 @@ [LibraryClasses]
 
 [LibraryClasses.common.SEC]
   PlatformSecLib|UefiCpuPkg/Library/PlatformSecLibNull/PlatformSecLibNull.inf
-!if $(TOOL_CHAIN_TAG) == "XCODE5"
-  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
-!else
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
-!endif
   HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf
   
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
   
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
@@ -145,12 +141,9 @@ [Components.IA32, Components.X64]
   UefiCpuPkg/Library/BaseXApicX2ApicLib/BaseXApicX2ApicLib.inf
   UefiCpuPkg/Library/CpuCommonFeaturesLib/CpuCommonFeaturesLib.inf
   UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
-!if $(TOOL_CHAIN_TAG) != "XCODE5"

[edk2-devel] [RFT PATCH v3 4/5] OvmfPkg: Drop special Xcode5 version of exception handler library

2023-03-31 Thread Ard Biesheuvel

The generic and XCODE5 versions of this library are now identical, so
drop the special case. The library will be removed entirely in a
subsequent patch.

Signed-off-by: Ard Biesheuvel 
Acked-by: Jiewen Yao 
---
 OvmfPkg/AmdSev/AmdSevX64.dsc | 4 
 OvmfPkg/CloudHv/CloudHvX64.dsc   | 4 
 OvmfPkg/IntelTdx/IntelTdxX64.dsc | 4 
 OvmfPkg/Microvm/MicrovmX64.dsc   | 4 
 OvmfPkg/OvmfPkgIa32.dsc  | 4 
 OvmfPkg/OvmfPkgIa32X64.dsc   | 4 
 OvmfPkg/OvmfPkgX64.dsc   | 4 
 OvmfPkg/OvmfXen.dsc  | 4 
 8 files changed, 32 deletions(-)

diff --git a/OvmfPkg/AmdSev/AmdSevX64.dsc b/OvmfPkg/AmdSev/AmdSevX64.dsc
index c005e474dd826759..943c4eed9831a1c5 100644
--- a/OvmfPkg/AmdSev/AmdSevX64.dsc
+++ b/OvmfPkg/AmdSev/AmdSevX64.dsc
@@ -224,11 +224,7 @@ [LibraryClasses.common.SEC]
   PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
   
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
   
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
-!if $(TOOL_CHAIN_TAG) == "XCODE5"
-  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
-!else
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
-!endif
   CcExitLib|OvmfPkg/Library/CcExitLib/SecCcExitLib.inf
   MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLib.inf
 
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index b9820cc14bee0693..cc2dd925bc940ea8 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -270,11 +270,7 @@ [LibraryClasses.common.SEC]
   PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
   
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
   
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
-!if $(TOOL_CHAIN_TAG) == "XCODE5"
-  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
-!else
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
-!endif
   CcExitLib|OvmfPkg/Library/CcExitLib/SecCcExitLib.inf
   MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLib.inf
 
diff --git a/OvmfPkg/IntelTdx/IntelTdxX64.dsc b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
index 5c56858d063b96bf..f734409055400859 100644
--- a/OvmfPkg/IntelTdx/IntelTdxX64.dsc
+++ b/OvmfPkg/IntelTdx/IntelTdxX64.dsc
@@ -238,11 +238,7 @@ [LibraryClasses.common.SEC]
   
ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf
   
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
   
MemoryAllocationLib|EmbeddedPkg/Library/PrePiMemoryAllocationLib/PrePiMemoryAllocationLib.inf
-!if $(TOOL_CHAIN_TAG) == "XCODE5"
-  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
-!else
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
-!endif
   CcExitLib|OvmfPkg/Library/CcExitLib/SecCcExitLib.inf
   MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLib.inf
   
PrePiHobListPointerLib|OvmfPkg/IntelTdx/PrePiHobListPointerLibTdx/PrePiHobListPointerLibTdx.inf
diff --git a/OvmfPkg/Microvm/MicrovmX64.dsc b/OvmfPkg/Microvm/MicrovmX64.dsc
index 384b0b7afc74e90f..e9aab515592ffcec 100644
--- a/OvmfPkg/Microvm/MicrovmX64.dsc
+++ b/OvmfPkg/Microvm/MicrovmX64.dsc
@@ -272,11 +272,7 @@ [LibraryClasses.common.SEC]
   PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
   
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
   
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
-!if $(TOOL_CHAIN_TAG) == "XCODE5"
-  
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
-!else
   
CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
-!endif
   CcExitLib|OvmfPkg/Library/CcExitLib/SecCcExitLib.inf
   MemEncryptSevLib|OvmfPkg/Library/BaseMemEncryptSevLib/SecMemEncryptSevLib.inf
 
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index a6db902f54ece86f..86177bb948999435 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -275,11 +275,7 @@ [LibraryClasses.common.SEC]
   PeiServicesLib|MdePkg/Library/PeiServicesLib/PeiServicesLib.inf
   
PeiServicesTablePointerLib|MdePkg/Library/PeiServicesTablePointerLibIdt/PeiServicesTablePointerLibIdt.inf
   
MemoryAllocationLib|MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf
-!if $(TOOL_CHAIN_TAG) == "XCODE5"
-

[edk2-devel] [RFT PATCH v3 2/5] UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version

2023-03-31 Thread Ard Biesheuvel

Currently, we use the non-Xcode5 version of ExceptionHandlerAsm.nasm
only for the SEC and PEI phases, and this version was not compatible
with the XCODE or LLD linkers, which do not permit absolute relocations
in read-only sections.

Given that SEC and PEI code typically executes in place from flash and
does not use page alignment for sections, we can simply emit the code
carrying the absolute symbol references into the .data segment instead.
This works around the linker's objections, and the resulting image will
be mapped executable in its entirety anyway. Since this is only needed
for XCODE, let's make this change conditionally using a preprocessor
macro.

Let's rename the .nasm file to reflect the fact that is used for the
SecPei flavor of this library only, and while at it, remove some
unnecessary absolute references.

Also update the Xcode specific version of this library, and use this
source file instead. This is necesessary, as the Xcode specific version
modifies its own code at runtime, which is not permitted in SEC or PEI.
Note that this also removes CET support from the Xcode5 specific build
of the SEC/PEI version of this library, but this is not needed this
early in any case, and this aligns it with other toolchains, which use
this version of the library, which does not have CET support either.

Signed-off-by: Ard Biesheuvel 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf 
|  4 +++-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/{ExceptionHandlerAsm.nasm => 
SecPeiExceptionHandlerAsm.nasm} | 12 
 
UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
   |  4 +++-
 3 files changed, 14 insertions(+), 6 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
index df44371fe018e06d..885bb6638ab58620 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf
@@ -28,7 +28,7 @@ [Sources.Ia32]
   Ia32/ArchInterruptDefs.h
 
 [Sources.X64]
-  X64/ExceptionHandlerAsm.nasm
+  X64/SecPeiExceptionHandlerAsm.nasm
   X64/ArchExceptionHandler.c
   X64/ArchInterruptDefs.h
 
@@ -58,3 +58,5 @@ [Pcd]
 [FeaturePcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackGuard## CONSUMES
 
+[BuildOptions]
+  XCODE:*_*_X64_PP_FLAGS = -DNO_ABSOLUTE_RELOCS_IN_TEXT
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/SecPeiExceptionHandlerAsm.nasm
similarity index 94%
rename from 
UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
rename to 
UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/SecPeiExceptionHandlerAsm.nasm
index aaf8d622e6f3b8f1..ec45c60181906c14 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
+++ 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/SecPeiExceptionHandlerAsm.nasm
@@ -27,7 +27,9 @@ extern ASM_PFX(CommonExceptionHandler)
 SECTION .data
 
 DEFAULT REL
+#ifndef NO_ABSOLUTE_RELOCS_IN_TEXT
 SECTION .text
+#endif
 
 ALIGN   8
 
@@ -51,6 +53,9 @@ HookAfterStubHeaderBegin:
 pushrax
 mov rax, HookAfterStubHeaderEnd
 jmp rax
+
+SECTION .text
+
 HookAfterStubHeaderEnd:
 mov rax, rsp
 and sp,  0xfff0; make sure 16-byte aligned for exception 
context
@@ -276,8 +281,7 @@ DrFinish:
 ; and make sure RSP is 16-byte aligned
 ;
 sub rsp, 4 * 8 + 8
-mov rax, ASM_PFX(CommonExceptionHandler)
-callrax
+callASM_PFX(CommonExceptionHandler)
 add rsp, 4 * 8 + 8
 
 cli
@@ -384,10 +388,10 @@ DoIret:
 ; comments here for definition of address map
 global ASM_PFX(AsmGetTemplateAddressMap)
 ASM_PFX(AsmGetTemplateAddressMap):
-mov rax, AsmIdtVectorBegin
+lea rax, [AsmIdtVectorBegin]
 mov qword [rcx], rax
 mov qword [rcx + 0x8],  (AsmIdtVectorEnd - AsmIdtVectorBegin) / 32
-mov rax, HookAfterStubHeaderBegin
+lea rax, [HookAfterStubHeaderBegin]
 mov qword [rcx + 0x10], rax
 ret
 
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
index 619b39d7f1de9ae3..17f872bb15eb0ff7 100644
--- 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
+++ 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
@@ -33,7 +33,7 @@ [Sources.Ia32]
   Ia32/ArchInterruptDefs.h
 
 [Sources.X64]
-  X64/Xcode5ExceptionHandlerAsm.nasm
+  X64/SecPeiExceptionHandlerAsm.nasm
   X64/ArchExceptionHandler.c
   X64/ArchInterruptDefs.h
 
@@ -63,3 +63,5 @@ [Pcd]
 [FeaturePcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackGuard

[edk2-devel] [RFT PATCH v3 3/5] UefiCpuPkg/CpuExceptionHandlerLib: Make runtime fixups XCODE-only

2023-03-31 Thread Ard Biesheuvel

The CPU exception handler library code was rewritten at some point to
populate the vector code templates with absolute references at runtime,
given that the XCODE linker does not permit absolute references in
executable code when creating PIE executables.

This is rather unfortunate, as this prevents us from using strict
permissions on the memory mappings, given that the .text section needs
to be writable at runtime for this arrangement to work.

So let's make this hack XCODE-only, by setting a preprocessor #define
from the command line when using the XCODE toolchain, and only including
the runtime fixup code when the macro is defined.

While at it, rename the Xcode5ExceptionHandlerAsm.nasm source file and
drop the Xcode5 prefix: this code is used by other toolchains too.

Signed-off-by: Ard Biesheuvel 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
|  5 -
 UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
|  4 +++-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
|  4 +++-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/{Xcode5ExceptionHandlerAsm.nasm 
=> ExceptionHandlerAsm.nasm} | 10 ++
 4 files changed, 20 insertions(+), 3 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
index d0f82095cf926e99..ee9df805c05df4f7 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
@@ -28,7 +28,7 @@ [Sources.Ia32]
   Ia32/ArchInterruptDefs.h
 
 [Sources.X64]
-  X64/Xcode5ExceptionHandlerAsm.nasm
+  X64/ExceptionHandlerAsm.nasm
   X64/ArchExceptionHandler.c
   X64/ArchInterruptDefs.h
 
@@ -61,3 +61,6 @@ [LibraryClasses]
   MemoryAllocationLib
   DebugLib
   CcExitLib
+
+[BuildOptions]
+  XCODE:*_*_X64_PP_FLAGS = -DNO_ABSOLUTE_RELOCS_IN_TEXT
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
index 5339f8e604045801..83970c54712f22a2 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
@@ -28,7 +28,7 @@ [Sources.Ia32]
   Ia32/ArchInterruptDefs.h
 
 [Sources.X64]
-  X64/Xcode5ExceptionHandlerAsm.nasm
+  X64/ExceptionHandlerAsm.nasm
   X64/ArchExceptionHandler.c
   X64/ArchInterruptDefs.h
 
@@ -62,3 +62,5 @@ [Pcd]
 [FeaturePcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackGuard## CONSUMES
 
+[BuildOptions]
+  XCODE:*_*_X64_PP_FLAGS = -DNO_ABSOLUTE_RELOCS_IN_TEXT
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
index 8f8a5dab79303f87..acd2936aef4490a5 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
@@ -28,7 +28,7 @@ [Sources.Ia32]
   Ia32/ArchInterruptDefs.h
 
 [Sources.X64]
-  X64/Xcode5ExceptionHandlerAsm.nasm
+  X64/ExceptionHandlerAsm.nasm
   X64/ArchExceptionHandler.c
   X64/ArchInterruptDefs.h
 
@@ -61,3 +61,5 @@ [Pcd]
 [FeaturePcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackGuard## CONSUMES
 
+[BuildOptions]
+  XCODE:*_*_X64_PP_FLAGS = -DNO_ABSOLUTE_RELOCS_IN_TEXT
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandlerAsm.nasm 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
similarity index 95%
rename from 
UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandlerAsm.nasm
rename to UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
index 957478574253e619..3823656ea7d4c3b8 100644
--- 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandlerAsm.nasm
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
@@ -59,7 +59,11 @@ AsmIdtVectorBegin:
 %rep  256
 pushstrict dword %[Vector] ; This instruction pushes sign-extended 
8-byte value on stack
 pushrax
+#ifdef NO_ABSOLUTE_RELOCS_IN_TEXT
 mov rax, strict qword 0; mov rax, ASM_PFX(CommonInterruptEntry)
+#else
+mov rax, ASM_PFX(CommonInterruptEntry)
+#endif
 jmp rax
 %assign Vector Vector+1
 %endrep
@@ -69,8 +73,12 @@ HookAfterStubHeaderBegin:
 pushstrict dword 0  ; 0 will be fixed
 VectorNum:
 pushrax
+#ifdef NO_ABSOLUTE_RELOCS_IN_TEXT
 mov rax, strict qword 0 ; mov rax, HookAfterStubHeaderEnd
 JmpAbsoluteAddress:
+#else
+mov rax, HookAfterStubHeaderEnd
+#endif
 jmp rax
 HookAfterStubHeaderEnd:
 mov rax, rsp
@@ -457,6 +465,7 @@

[edk2-devel] [RFT PATCH v3 1/5] BaseTools/tools_def CLANGDWARF: Permit text relocations

2023-03-31 Thread Ard Biesheuvel

We rely on PIE executables to get the codegen that is suitable for
PE/COFF conversion where the resulting executables can be loaded
anywhere in the address space.

However, ELF linkers may default to disallowing text relocations in PIE
executables, as this would require text segments to be updated at
runtime, which is bad for security and increases the copy-on-write
footprint of ELF executables and shared libraries.

However, none of those concerns apply to PE/COFF executables in the
context of EFI, which are copied into memory rather than mmap()'ed, and
fixed up by the loader before launch.

So pass -z notext to the LLD linker to permit runtime relocations in
read-only sections.

Signed-off-by: Ard Biesheuvel 
---
 BaseTools/Conf/tools_def.template | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index ae43101853870c6d..5a3af55bfb09d753 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -2870,7 +2870,7 @@ DEFINE CLANGDWARF_X64_PREFIX= ENV(CLANG_BIN)
 DEFINE CLANGDWARF_IA32_X64_DLINK_COMMON   = -nostdlib -Wl,-q,--gc-sections -z 
max-page-size=0x40
 DEFINE CLANGDWARF_DLINK2_FLAGS_COMMON = 
-Wl,--script=$(EDK_TOOLS_PATH)/Scripts/ClangBase.lds
 DEFINE CLANGDWARF_IA32_X64_ASLDLINK_FLAGS = 
DEF(CLANGDWARF_IA32_X64_DLINK_COMMON) -Wl,--defsym=PECOFF_HEADER_SIZE=0 
DEF(CLANGDWARF_DLINK2_FLAGS_COMMON) -Wl,--entry,ReferenceAcpiTable -u 
ReferenceAcpiTable
-DEFINE CLANGDWARF_IA32_X64_DLINK_FLAGS= 
DEF(CLANGDWARF_IA32_X64_DLINK_COMMON) -Wl,--entry,$(IMAGE_ENTRY_POINT) -u 
$(IMAGE_ENTRY_POINT) -Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map,--whole-archive
+DEFINE CLANGDWARF_IA32_X64_DLINK_FLAGS= 
DEF(CLANGDWARF_IA32_X64_DLINK_COMMON) -Wl,--entry,$(IMAGE_ENTRY_POINT) -u 
$(IMAGE_ENTRY_POINT) 
-Wl,-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map,--whole-archive -Wl,-z,notext
 DEFINE CLANGDWARF_IA32_DLINK2_FLAGS   = 
-Wl,--defsym=PECOFF_HEADER_SIZE=0x220 DEF(CLANGDWARF_DLINK2_FLAGS_COMMON)
 DEFINE CLANGDWARF_X64_DLINK2_FLAGS= 
-Wl,--defsym=PECOFF_HEADER_SIZE=0x228 DEF(CLANGDWARF_DLINK2_FLAGS_COMMON)
 
-- 
2.39.2



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

[edk2-devel] [RFT PATCH v3 0/5] UefiCpuPkg, OvmfPkg: Simplify CpuExceptionHandlerLib

2023-03-31 Thread Ard Biesheuvel

We have a special version of CpuExceptionHandlerLib for XCODE5, whose
linker (LLD) does not permit absolute symbol references in read-only
sections.

Instead of fixing this up at runtime for all toolchains (which is done
by writing the fixed up values to the .text section, which we'd prefer
to avoid), tweak the SEC/PEI version so it does not need this, and
update the remaining versions to only incorporate this logic when using
the XCODE toolchain.

Changes since v3:
-  As Marvin points out, using '-read_only_relocs suppress' with the X64
   XCODE linker is a terrible idea, as it corrupts the resulting PE
   binaries, so instead, let's do the following:
   . tweak the SEC/PEI version of the library so the relocs are emitted
 into .data when using XCODE;
   . tweak the other versions so the runtime fixups are only done when
 using XCODE
- add acks from Jiewen and Ray

Changes since v2:
- pass linker switches to permit absolute relocations in read-only
  regions, and keep all code in .text

Cc: "Ni, Ray" 
Cc: Andrew Fish 
Cc: "Kinney, Michael D" 
Cc: "Liu, Zhiguang" 
Cc: Rebecca Cran 
Cc: Tom Lendacky 
Cc: Marvin HÃ¤user 

Ard Biesheuvel (5):
  BaseTools/tools_def CLANGDWARF: Permit text relocations
  UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version
  UefiCpuPkg/CpuExceptionHandlerLib: Make runtime fixups XCODE-only
  OvmfPkg: Drop special Xcode5 version of exception handler library
  UefiCpuPkg/CpuExceptionHandlerLib: Drop special XCODE5 version

 BaseTools/Conf/tools_def.template  
  |   2 +-
 OvmfPkg/AmdSev/AmdSevX64.dsc   
  |   4 -
 OvmfPkg/CloudHv/CloudHvX64.dsc 
  |   4 -
 OvmfPkg/IntelTdx/IntelTdxX64.dsc   
  |   4 -
 OvmfPkg/Microvm/MicrovmX64.dsc 
  |   4 -
 OvmfPkg/OvmfPkgIa32.dsc
  |   4 -
 OvmfPkg/OvmfPkgIa32X64.dsc 
  |   4 -
 OvmfPkg/OvmfPkgX64.dsc 
  |   4 -
 OvmfPkg/OvmfXen.dsc
  |   4 -
 UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf
  |   5 +-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf
  |   4 +-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/SecPeiCpuExceptionHandlerLib.inf 
  |   4 +-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
  |   4 +-
 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm 
  | 116 +---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/{Xcode5ExceptionHandlerAsm.nasm 
=> SecPeiExceptionHandlerAsm.nasm} | 108 +++---
 
UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
 |  65 ---
 
UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.uni
 |  18 ---
 UefiCpuPkg/UefiCpuPkg.dsc  
  |   7 --
 18 files changed, 133 insertions(+), 232 deletions(-)
 rename 
UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/{Xcode5ExceptionHandlerAsm.nasm 
=> SecPeiExceptionHandlerAsm.nasm} (70%)
 delete mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.inf
 delete mode 100644 
UefiCpuPkg/Library/CpuExceptionHandlerLib/Xcode5SecPeiCpuExceptionHandlerLib.uni

-- 
2.39.2



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

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

2023-03-31 Thread Ard Biesheuvel

On Fri, 31 Mar 2023 at 10:29, Marvin Häuser  wrote:
>
>
> > On 31. Mar 2023, at 09:39, Ard Biesheuvel  wrote:
> > Hi Marvin,
> >
> > Thanks for the context.
> >
> >
> > On Thu, 30 Mar 2023 at 23:54, Marvin Häuser  wrote:
> >>
> >> Hi Ard,
> >>
> >> Sorry, I cannot preserve the CC list as the groups.io interface doesn't 
> >> seem to allow it. Can you please CC me on future revisions?
> >>
> >> This patch will badly corrupt binaries. I cannot cite a source right now 
> >> (if you want me to, please remind me in your response, so I can look it up 
> >> tomorrow), but for X64 (but not IA32, which is why this is enabled there), 
> >> relocs are relative to the first *writable* segment. In other words, any 
> >> relocation to __TEXT will badly corrupt binaries this way.
> >
> > OMG.
> >
> > I can't believe how buggy all this stuff is. But I can confirm that
> > the resulting binaries don't look right, even though they appear to
> > boot fine.
>
> Codegen does not change from the suppress flag, so there will be no 
> additional text relocs beyond those you introduced. As they target the 
> exception handler, I guess you’d need to actively provoke the broken code 
> paths (and may end up with a nice recursion :) ).
>

I understand that the codegen is the same. I was specifically talking
about the PE relocations, which seem to be lacking entirely.

> > In particular, when I dump the PE relocations using
> > llvm-readobj --coff-basereloc, I don't see any relocations referring
> > to the .text section.
> >
> >> In AUDK, we support this with two essential changes. The first is that we 
> >> always generate a writable dummy segment at the beginning of the address 
> >> space [1], making the relocs relative to the image base. The second is 
> >> that in ocmtoc, our fork of the abandoned (and pretty badly-bugged) Apple 
> >> mtoc, we explicitly require this segment to be present and verify its 
> >> virtual address is the minimum virtual address [2]. It is then omitted 
> >> from the conversion process [3]. I suggest you replicate these changes and 
> >> fully switch to ocmtoc for XCODE5 builds.
> >
> > I'm not going to do any of that. Instead, I am going to drop this
> > change, and do the following:
> >
> > - modify the SecPei version of CpuExceptionHandlerLib to put the
> > vector templates in .data, as I proposed before. This works around the
> > issue, and given that SEC/PEI is assumed to be read-only anyway (as it
> > may execute in place from flash) and does not use page alignment for
> > the sections due to size constraints, it is reasonable to assume that
> > .text and .data will be mapped executable anyway.
>
> Well, that assumption is more than fair to make for the status quo platforms, 
> but this is just another rock in the way of doing things the right way (even 
> if it’s just VMs).
>

How so? SEC and PEI could be mapped read-only today, it's just that we
never bother.

> Cc Gerd for an OVMF security perspective. Is PEI-time memory protection 
> something you’d be interested in in the future?
>

My WXN series for ARM maps all PEIMs read-only, and turns off
shadowing entirely (which makes no sense for VMs). So we have most of
what we need to do that, and this change has no bearing on that.

> >
> > - update the version that performs the runtime fixups to only do so
> > when using the XCODE toolchain - we can phase that out once we drop
> > XCODE support.
>
> I agree if there’s an actual plan on doing that. We depend on XCODE5 
> downstream, but I think it would literally be easier for us if the upstream 
> version was dropped than rebasing against hacks that our slightly modded 
> variant does not require.
>
> Cc Andrew and Rebecca. I don’t know anyone else who might still be using 
> XCODE5. Any objections to dropping it? If so, any plans to pick up my 
> proposed changes instead?
>

I wouldn't mind dropping it. In fact, I'm wondering - given that you
need to install nasm and iasl anyway - if it wouldn't make more sense
to use the CLANGPDB toolchain on macOS, and avoid the mtoc mess
entirely?


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102254): https://edk2.groups.io/g/devel/message/102254
Mute This Topic: https://groups.io/mt/97960758/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/1] ArmPkg/PlatformBootManagerLib: Add path to boot UEFI Shell over UiApp

2023-03-31 Thread PierreGondois


Hello Ard,

On 2/13/23 09:39, Pierre Gondois wrote:

Hello Ard,

On 2/9/23 17:57, Ard Biesheuvel wrote:

On Tue, 7 Feb 2023 at 10:07,  wrote:


From: Pierre Gondois 

The UEFI Shell is a non-active boot option, at the opposite of UiApp.
If no valid boot option is found, UiApp is selected. UiApp requires a
human interaction. When installing a new EDKII image in CIs or when
scripting is required, this is problematic.

If no valid boot option is discovered, add a path to directly go to
the UEFI Shell where the startup.nsh script is automatically executed.
The UEFI Shell is launched after connecting possible devices, but
before the reset that is meant to automatically make them visible.

The new PcdUefiShellDefaultBootEnable must be set to TRUE to enable
this behaviour. The Pcd is set to false by default.



Is this similar to how we implemented this on RPi4? IIRC, a similar
issue came up there as well.


I'm not finding an equivalent for the Rpi4. I see that the
BootDiscoveryPolicy was added, but this regards which devices to connect
during boot IIUC. The UEFI Shell also seems to have been added to the
Boot Manager Menu, but this should not select the UEFI Shell by default.



Are you referring to the following ?
https://edk2.groups.io/g/devel/message/60719

If yes I don't think this patch aims to achieve the same thing.
The goal here is to reach the UEFI shell (i.e. make it an active option).
I believe the patch mentioned above doesn't modify that and is more about
making it visible in UiApp BootManager.

Please let me know if you were referring to another modification,
Regards,
Pierre


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

Re: [edk2-devel] [RFT PATCH v2 1/6] BaseTools/tools_def XCODE: Link X64 with -read_only_relocs suppress

2023-03-31 Thread Marvin Häuser



> On 31. Mar 2023, at 09:39, Ard Biesheuvel  wrote:
> Hi Marvin,
> 
> Thanks for the context.
> 
> 
> On Thu, 30 Mar 2023 at 23:54, Marvin Häuser  wrote:
>> 
>> Hi Ard,
>> 
>> Sorry, I cannot preserve the CC list as the groups.io interface doesn't seem 
>> to allow it. Can you please CC me on future revisions?
>> 
>> This patch will badly corrupt binaries. I cannot cite a source right now (if 
>> you want me to, please remind me in your response, so I can look it up 
>> tomorrow), but for X64 (but not IA32, which is why this is enabled there), 
>> relocs are relative to the first *writable* segment. In other words, any 
>> relocation to __TEXT will badly corrupt binaries this way.
> 
> OMG.
> 
> I can't believe how buggy all this stuff is. But I can confirm that
> the resulting binaries don't look right, even though they appear to
> boot fine.

Codegen does not change from the suppress flag, so there will be no additional 
text relocs beyond those you introduced. As they target the exception handler, 
I guess you’d need to actively provoke the broken code paths (and may end up 
with a nice recursion :) ).

> In particular, when I dump the PE relocations using
> llvm-readobj --coff-basereloc, I don't see any relocations referring
> to the .text section.
> 
>> In AUDK, we support this with two essential changes. The first is that we 
>> always generate a writable dummy segment at the beginning of the address 
>> space [1], making the relocs relative to the image base. The second is that 
>> in ocmtoc, our fork of the abandoned (and pretty badly-bugged) Apple mtoc, 
>> we explicitly require this segment to be present and verify its virtual 
>> address is the minimum virtual address [2]. It is then omitted from the 
>> conversion process [3]. I suggest you replicate these changes and fully 
>> switch to ocmtoc for XCODE5 builds.
> 
> I'm not going to do any of that. Instead, I am going to drop this
> change, and do the following:
> 
> - modify the SecPei version of CpuExceptionHandlerLib to put the
> vector templates in .data, as I proposed before. This works around the
> issue, and given that SEC/PEI is assumed to be read-only anyway (as it
> may execute in place from flash) and does not use page alignment for
> the sections due to size constraints, it is reasonable to assume that
> .text and .data will be mapped executable anyway.

Well, that assumption is more than fair to make for the status quo platforms, 
but this is just another rock in the way of doing things the right way (even if 
it’s just VMs).

Cc Gerd for an OVMF security perspective. Is PEI-time memory protection 
something you’d be interested in in the future?

> 
> - update the version that performs the runtime fixups to only do so
> when using the XCODE toolchain - we can phase that out once we drop
> XCODE support.

I agree if there’s an actual plan on doing that. We depend on XCODE5 
downstream, but I think it would literally be easier for us if the upstream 
version was dropped than rebasing against hacks that our slightly modded 
variant does not require.

Cc Andrew and Rebecca. I don’t know anyone else who might still be using 
XCODE5. Any objections to dropping it? If so, any plans to pick up my proposed 
changes instead?

Best regards,
Marvin


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

Re: [edk2-devel] [PATCH V1 1/1] OvmfPkg/PlatformPei: Skip PlatformInitEmuVariableNvStore in SEV guest

2023-03-31 Thread Gerd Hoffmann

On Fri, Mar 31, 2023 at 03:59:56PM +0800, joeyli wrote:
> Hi Gerd,
> 
> On Thu, Mar 30, 2023 at 09:50:53AM +0200, Gerd Hoffmann wrote:
> > On Wed, Mar 29, 2023 at 01:23:10PM +0800, Min Xu wrote:
> > > From: Min M Xu 
> > > 
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4379
> > > 
> > > PlatformInitEmuVariableNvStore is called to initialize the
> > > EmuVariableNvStore with the content pointed by
> > > PcdOvmfFlashNvStorageVariableBase. This is because when OVMF is launched
> > > with -bios parameter, UEFI variables will be partially emulated, and
> > > non-volatile variables may lose their contents after a reboot. This makes
> > > the secure boot feature not working.
> > > 
> > > But in SEV guest, this design doesn't work. Because at this point the
> > > variable store mapping is still private/encrypted, OVMF will see
> > > ciphertext. So we skip the call of PlatformInitEmuVariableNvStore in
> > > SEV guest.
> > 
> > I'd suggest to simply build without -D SECURE_BOOT_ENABLE instead.
> > Without initializing the emu var store you will not get a functional
> > secure boot setup anyway.
> 
> In our case, we already shipped ovmf with -D SECURE_BOOT_ENABLE in a couple
> of versions. Removing it will causes problem in VM live migration.

Hmm?  qemu live-migrates the rom image too.  Only after poweroff and
reboot the guest will see an updated firmware image.

> I will prefer Min M's solution, until SEV experts found better
> solution.

I'd prefer to not poke holes into secure boot.  Re-Initializing the emu
var store from rom on each reset is also needed for security reasons in
case the efi variable store is not in smm-protected flash memory.

take care,
  Gerd



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

Re: [edk2-devel] [RFT PATCH v2 4/6] UefiCpuPkg/CpuExceptionHandlerLib: Remove needless runtime fixups

2023-03-31 Thread Marvin Häuser

Hi Ray,

Definitely - this is just an optimisation “while we’re at it“, nothing urgent.

Best regards,
Marvin

> On 31. Mar 2023, at 07:09, Ni, Ray  wrote:
> 
> 
> 
> diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionH=
> andlerAsm.nasm b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHan=
> dlerAsm.nasm
> similarity index 92%
> rename from UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHa=
> ndlerAsm.nasm
> rename to UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm=
> .nasm
> index 957478574253e619..10af4cfcdb6b1ea2 100644
> --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/Xcode5ExceptionHandlerA=
> sm.nasm
> +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
> @@ -59,7 +59,7 @@ AsmIdtVectorBegin:
> %rep 256=0D
> push strict dword %[Vector] ; This instruction pushes sign-extended=
> 8-byte value on stack=0D
> push rax=0D
> - mov rax, strict qword 0 ; mov rax, ASM_PFX(CommonInterruptE=
> ntry)=0D
> + mov rax, ASM_PFX(CommonInterruptEntry)=0D
> I'm fairly certain this can be a relative reference, as the code doesn't seem 
> to be copied away (as opposed to HookAfterStubHeaderBegin). If true, this 
> would save 256 relocs, which sounds quite nice. Would you mind verifying? 
> Thanks!
> 
> Marvin,
> 
> You are right the mov can be replaced with “lea”. But, we need to analyze if 
> using lea, the size of each idt stub is fixed or variant (today the size is 
> fixed, so StubSize = TotalSize / 256).
> 
> Another thing we need to evaluate is the impact to “Hook after” feature 
> because “hook after” stub is very like the idt stub.
> 
> I think we can firstly use Ard’s solution. Later to evaluate to eliminate 
> unnecessary absolute reference.
> 
> Thanks,
> 
> Ray


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

Re: [edk2-devel] [PATCH 0/6] Substract TME-MK KEY_ID_BITS from CPU max PA

2023-03-31 Thread Ni, Ray

Gerd,
Can you give a Reviewed-by/Acked-by for the patch series?

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ni, Ray
> Sent: Friday, March 31, 2023 3:25 PM
> To: kra...@redhat.com; Xu, Min M ; Liu, Zhiguang
> 
> Cc: devel@edk2.groups.io; Tom Lendacky 
> Subject: Re: [edk2-devel] [PATCH 0/6] Substract TME-MK KEY_ID_BITS from
> CPU max PA
> 
> @Xu, Min M, can you check if Gerd's comment is valid?
> 
> Gerd,
> This Bugzilla captures the same idea:
> https://bugzilla.tianocore.org/show_bug.cgi?id=3394
> Originally from Laszlo. +@Liu, Zhiguang who will work on patch submission
> later.
> 
> Thanks,
> Ray
> 
> > -Original Message-
> > From: kra...@redhat.com 
> > Sent: Thursday, March 30, 2023 5:03 PM
> > To: Ni, Ray 
> > Cc: devel@edk2.groups.io; Tom Lendacky 
> > Subject: Re: [edk2-devel] [PATCH 0/6] Substract TME-MK KEY_ID_BITS
> from CPU max PA
> >
> >   Hi,
> >
> > > For tdx, the actual max physical address bits is decreased by the
> KEY_ID_BITS bits.
> > > But the max physical address bits reported from CPUID instruction don't
> change.
> >
> > I guess the physical address bits calculation for tdx needs adjustment
> > then.  Right now we have:
> >
> >   if (TdIsEnabled ()) {
> > if (TdSharedPageMask () == (1ULL << 47)) {
> >   PhysMemAddressWidth = 48;
> > } else {
> >   PhysMemAddressWidth = 52;
> > }
> >   }
> >
> >
> > See PlatformAddressWidthInitialization() in PlatformInitLib/MemDetect.c
> >
> > Which would be the third place needing the same logic.  Maybe worth
> > thinking about a helper function in a library somewhere, so we don't
> > cut the same code snippet again and again ...
> >
> > take care,
> >   Gerd
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102249): https://edk2.groups.io/g/devel/message/102249
Mute This Topic: https://groups.io/mt/97767965/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] [RFT PATCH v2 3/6] UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version

2023-03-31 Thread Ni, Ray

Thanks!
Overall, the patch greatly simplifies the CpuExceptionHandlerLib.
Even I sometimes am lost of which C/NASM contributes to which instance.

With the enhanced commit log, Reviewed-by: Ray Ni 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ard
> Biesheuvel
> Sent: Friday, March 31, 2023 3:41 PM
> To: devel@edk2.groups.io; Ni, Ray 
> Cc: Andrew Fish ; Kinney, Michael D
> ; Liu, Zhiguang ;
> Rebecca Cran ; Tom Lendacky
> 
> Subject: Re: [edk2-devel] [RFT PATCH v2 3/6]
> UefiCpuPkg/CpuExceptionHandlerLib: Use single SEC/PEI version
> 
> On Fri, 31 Mar 2023 at 06:24, Ni, Ray  wrote:
> >
> > Thanks for the change.
> >
> > But it doesn't highlight another impact due to this change: CET logic is
> removed from the SEC/PEI version.
> 
> No the ordinary SEC/PEI version does not have the CET logic - only the
> XCODE version does.
> 
> > It's not an issue because CET is only enabled in SMM environment today.
> > But better to highlight the impact in the commit message, and explicitly say
> that limitation in the SecPeiCpuExceptionHandlerLib.inf file.
> >
> 
> I am going to have to revisit this anyway, but I will put some more
> context about this in the commit log.
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#102248): https://edk2.groups.io/g/devel/message/102248
Mute This Topic: https://groups.io/mt/97960765/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 V1 1/1] OvmfPkg/PlatformPei: Skip PlatformInitEmuVariableNvStore in SEV guest

2023-03-31 Thread joeyli via groups.io

Hi Gerd,

On Thu, Mar 30, 2023 at 09:50:53AM +0200, Gerd Hoffmann wrote:
> On Wed, Mar 29, 2023 at 01:23:10PM +0800, Min Xu wrote:
> > From: Min M Xu 
> > 
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4379
> > 
> > PlatformInitEmuVariableNvStore is called to initialize the
> > EmuVariableNvStore with the content pointed by
> > PcdOvmfFlashNvStorageVariableBase. This is because when OVMF is launched
> > with -bios parameter, UEFI variables will be partially emulated, and
> > non-volatile variables may lose their contents after a reboot. This makes
> > the secure boot feature not working.
> > 
> > But in SEV guest, this design doesn't work. Because at this point the
> > variable store mapping is still private/encrypted, OVMF will see
> > ciphertext. So we skip the call of PlatformInitEmuVariableNvStore in
> > SEV guest.
> 
> I'd suggest to simply build without -D SECURE_BOOT_ENABLE instead.
> Without initializing the emu var store you will not get a functional
> secure boot setup anyway.
>

In our case, we already shipped ovmf with -D SECURE_BOOT_ENABLE in a couple
of versions. Removing it will causes problem in VM live migration. I will prefer
Min M's solution, until SEV experts found better solution.

Thank!
Joey Lee 


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

Re: [edk2-devel] [PATCH v6 6/6] UefiCpuPkg: Implements SmmCpuFeaturesLib for AMD Family

2023-03-31 Thread Ni, Ray

It's a bit wired that AMD version of SmmCpuFeaturesLib calls AMD version of 
SmmSmramSaveStateLib.
The question naturally becomes: why not integrate the two lib implementations 
together to avoid
creating the SmmSmramSaveStateLib library class? Because I cannot imagine 
AmdSmmCpuFeaturesLib calls
to IntelSmmSmramSaveStateLib.

But I like the idea of separating the SMM save state access logic out of the 
SmmCpuFeaturesLib.
Do you think CpuSmm driver calling the SmmSmramSaveStateLib is better?


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Abdul
> Lateef Attar via groups.io
> Sent: Saturday, March 25, 2023 1:39 PM
> To: devel@edk2.groups.io
> Cc: Abdul Lateef Attar ; Paul Grimes
> ; Garrett Kirkendall ;
> Abner Chang ; Dong, Eric ;
> Ni, Ray ; Kumar, Rahul R ;
> Abdul Lateef Attar 
> Subject: [edk2-devel] [PATCH v6 6/6] UefiCpuPkg: Implements
> SmmCpuFeaturesLib for AMD Family
> 
> From: Abdul Lateef Attar 
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4182
> 
> Implements interfaces to read and write save state
> registers of AMD's processor family.
> Initializes processor SMMADDR and MASK depends
> on PcdSmrrEnable flag.
> Program or corrects the IP once control returns from SMM.
> 
> Cc: Paul Grimes 
> Cc: Garrett Kirkendall 
> Cc: Abner Chang 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Rahul Kumar 
> Signed-off-by: Abdul Lateef Attar 
> Reviewed-by: Abner Chang 
> ---
>  .../AmdSmmCpuFeaturesLib.inf  |   6 +
>  .../SmmCpuFeaturesLib/AmdSmmCpuFeaturesLib.c  | 106
> +-
>  2 files changed, 109 insertions(+), 3 deletions(-)
> 
> diff --git
> a/UefiCpuPkg/Library/SmmCpuFeaturesLib/AmdSmmCpuFeaturesLib.inf
> b/UefiCpuPkg/Library/SmmCpuFeaturesLib/AmdSmmCpuFeaturesLib.inf
> index 4c77efc64462..9d5b8c2e972d 100644
> --- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/AmdSmmCpuFeaturesLib.inf
> +++
> b/UefiCpuPkg/Library/SmmCpuFeaturesLib/AmdSmmCpuFeaturesLib.inf
> @@ -31,3 +31,9 @@ [LibraryClasses]
>PcdLib
>MemoryAllocationLib
>DebugLib
> +  SmmSmramSaveStateLib
> +
> +[FeaturePcd]
> +  gUefiCpuPkgTokenSpaceGuid.PcdSmrrEnable   ## CONSUMES
> +  gUefiCpuPkgTokenSpaceGuid.PcdSmmFeatureControlEnable  ##
> CONSUMES
> +
> diff --git
> a/UefiCpuPkg/Library/SmmCpuFeaturesLib/AmdSmmCpuFeaturesLib.c
> b/UefiCpuPkg/Library/SmmCpuFeaturesLib/AmdSmmCpuFeaturesLib.c
> index c74e1a0c0c5b..af45be3e265a 100644
> --- a/UefiCpuPkg/Library/SmmCpuFeaturesLib/AmdSmmCpuFeaturesLib.c
> +++ b/UefiCpuPkg/Library/SmmCpuFeaturesLib/AmdSmmCpuFeaturesLib.c
> @@ -11,6 +11,21 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +// EFER register LMA bit
> +#define LMA  BIT10
> +
> +// Machine Specific Registers (MSRs)
> +#define SMMADDR_ADDRESS  0xC0010112ul
> +#define SMMMASK_ADDRESS  0xC0010113ul
> +#define EFER_ADDRESS 0XC080ul
> +
> +// The mode of the CPU at the time an SMI occurs
> +STATIC UINT8  mSmmSaveStateRegisterLma;
> 
>  /**
>Read an SMM Save State register on the target processor.  If this function
> @@ -39,7 +54,7 @@ SmmCpuFeaturesReadSaveStateRegister (
>OUT VOID *Buffer
>)
>  {
> -  return EFI_SUCCESS;
> +  return SmramSaveStateReadRegister (CpuIndex, Register, Width, Buffer);
>  }
> 
>  /**
> @@ -67,7 +82,7 @@ SmmCpuFeaturesWriteSaveStateRegister (
>IN CONST VOID   *Buffer
>)
>  {
> -  return EFI_SUCCESS;
> +  return SmramSaveStateWriteRegister (CpuIndex, Register, Width, Buffer);
>  }
> 
>  /**
> @@ -82,6 +97,13 @@ CpuFeaturesLibInitialization (
>VOID
>)
>  {
> +  UINT32  LMAValue;
> +
> +  LMAValue = (UINT32)AsmReadMsr64 (EFER_ADDRESS) & LMA;
> +  mSmmSaveStateRegisterLma =
> EFI_SMM_SAVE_STATE_REGISTER_LMA_32BIT;
> +  if (LMAValue) {
> +mSmmSaveStateRegisterLma =
> EFI_SMM_SAVE_STATE_REGISTER_LMA_64BIT;
> +  }
>  }
> 
>  /**
> @@ -117,6 +139,52 @@ SmmCpuFeaturesInitializeProcessor (
>IN CPU_HOT_PLUG_DATA  *CpuHotPlugData
>)
>  {
> +  AMD_SMRAM_SAVE_STATE_MAP  *CpuState;
> +  UINT32LMAValue;
> +
> +  //
> +  // Configure SMBASE.
> +  //
> +  CpuState = (AMD_SMRAM_SAVE_STATE_MAP
> *)(UINTN)(SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET);
> +  CpuState->x64.SMBASE = (UINT32)CpuHotPlugData->SmBase[CpuIndex];
> +
> +  // Re-initialize the value of mSmmSaveStateRegisterLma flag which might
> have been changed in PiCpuSmmDxeSmm Driver
> +  // Entry point, to make sure correct value on AMD platform is assigned to
> be used by SmmCpuFeaturesLib.
> +  LMAValue = (UINT32)AsmReadMsr64 (EFER_ADDRESS) & LMA;
> +  mSmmSaveStateRegisterLma =
> EFI_SMM_SAVE_STATE_REGISTER_LMA_32BIT;
> +  if (LMAValue) {
> +mSmmSaveStateRegisterLma =
> EFI_SMM_SAVE_STATE_REGISTER_LMA_64BIT;
> +  }
> +
> +  //
> +  // If SMRR is supported, then program SMRR base/mask MSRs.
> +  // The EFI_MSR_SMRR_PHYS_MASK_VALID bit is not set until

1 2 >

1 - 100 of 110 matches

Mail list logo