Background:
For arch X64, system will enable the page table in SPI to cover 0-512G range
via CR4.PAE & MSR.LME & CR0.PG & CR3 setting (see ResetVector code). Existing
code doesn't cover the higher address access above 512G before memory-discovered
callback. That will be potential problem if system access the higher address
after the transition from temporary RAM to permanent MEM RAM.

Solution:
This patch is to migrate page table to permanent memory to map entire physical
address space if CR0.PG is set during temporary RAM Done.

Change-Id: I29bdb078ef567ed9455d1328cb007f4f60a617a2
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zeng Star <star.zeng@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com>
---
 UefiCpuPkg/SecCore/SecCore.inf       |   1 +
 UefiCpuPkg/SecCore/SecCoreNative.inf |   1 +
 UefiCpuPkg/SecCore/SecMain.c         | 164 +++++++++++++++++++++++++++++++++++
 UefiCpuPkg/SecCore/SecMain.h         |   4 +
 4 files changed, 170 insertions(+)

diff --git a/UefiCpuPkg/SecCore/SecCore.inf b/UefiCpuPkg/SecCore/SecCore.inf
index 3758aded3b..cab69b8b97 100644
--- a/UefiCpuPkg/SecCore/SecCore.inf
+++ b/UefiCpuPkg/SecCore/SecCore.inf
@@ -53,10 +53,11 @@
   CpuExceptionHandlerLib
   ReportStatusCodeLib
   PeiServicesLib
   PeiServicesTablePointerLib
   HobLib
+  CpuPageTableLib
 
 [Ppis]
   ## SOMETIMES_CONSUMES
   ## PRODUCES
   gEfiSecPlatformInformationPpiGuid
diff --git a/UefiCpuPkg/SecCore/SecCoreNative.inf b/UefiCpuPkg/SecCore/SecCoreNative.inf
index 1ee6ff7d88..fa241cca94 100644
--- a/UefiCpuPkg/SecCore/SecCoreNative.inf
+++ b/UefiCpuPkg/SecCore/SecCoreNative.inf
@@ -50,10 +50,11 @@
   CpuExceptionHandlerLib
   ReportStatusCodeLib
   PeiServicesLib
   PeiServicesTablePointerLib
   HobLib
+  CpuPageTableLib
 
 [Ppis]
   ## SOMETIMES_CONSUMES
   ## PRODUCES
   gEfiSecPlatformInformationPpiGuid
diff --git a/UefiCpuPkg/SecCore/SecMain.c b/UefiCpuPkg/SecCore/SecMain.c
index 95375850ec..d0dc76e804 100644
--- a/UefiCpuPkg/SecCore/SecMain.c
+++ b/UefiCpuPkg/SecCore/SecMain.c
@@ -70,10 +70,159 @@ MigrateGdt (
   AsmWriteGdtr (&Gdtr);
 
   return EFI_SUCCESS;
 }
 
+/**
+  Migrate page table to permanent memory mapping entire physical address space.
+
+  @retval   EFI_SUCCESS           The PageTable was migrated successfully.
+  @retval   EFI_UNSUPPORTED       Unsupport to migrate page table to permanent memory if IA-32e Mode not actived.
+  @retval   EFI_OUT_OF_RESOURCES  The PageTable could not be migrated due to lack of available memory.
+
+**/
+EFI_STATUS
+MigratePageTable (
+  VOID
+  )
+{
+  EFI_STATUS                      Status;
+  IA32_CR4                        Cr4;
+  BOOLEAN                         Page5LevelSupport;
+  UINT32                          RegEax;
+  UINT32                          RegEdx;
+  BOOLEAN                         Page1GSupport;
+  PAGING_MODE                     PagingMode;
+
+  CPUID_VIR_PHY_ADDRESS_SIZE_EAX  VirPhyAddressSize;
+  UINT32                          MaxExtendedFunctionId;
+
+  UINTN                           PageTable;
+  VOID                            *Buffer;
+  UINTN                           BufferSize;
+  IA32_MAP_ATTRIBUTE              MapAttribute;
+  IA32_MAP_ATTRIBUTE              MapMask;
+
+  VirPhyAddressSize.Uint32     = 0;
+  PageTable                    = 0;
+  Buffer                       = NULL;
+  BufferSize                   = 0;
+  MapAttribute.Uint64          = 0;
+  MapMask.Uint64               = MAX_UINT64;
+  MapAttribute.Bits.Present    = 1;
+  MapAttribute.Bits.ReadWrite  = 1;
+
+  //
+  // Check CPU runs in 64bit mode or 32bit mode
+  //
+  if (sizeof (UINTN) == sizeof (UINT32)) {
+    DEBUG ((DEBUG_WARN, "MigratePageTable: CPU runs in 32bit mode, unsupport to migrate page table to permanent memory.\n"));
+    ASSERT (TRUE);
+    return EFI_UNSUPPORTED;
+  }
+
+  //
+  // Check Page5Level Support or not.
+  //
+  Cr4.UintN = AsmReadCr4 ();
+  Page5LevelSupport = (Cr4.Bits.LA57 ? TRUE : FALSE);
+
+  //
+  // Check Page1G Support or not.
+  //
+  Page1GSupport = FALSE;
+  AsmCpuid (CPUID_EXTENDED_FUNCTION, &RegEax, NULL, NULL, NULL);
+  if (RegEax >= CPUID_EXTENDED_CPU_SIG) {
+    AsmCpuid (CPUID_EXTENDED_CPU_SIG, NULL, NULL, NULL, &RegEdx);
+    if ((RegEdx & BIT26) != 0) {
+      Page1GSupport = TRUE;
+    }
+  }
+
+  //
+  // Decide Paging Mode according Page5LevelSupport & Page1GSupport.
+  //
+  PagingMode = Paging5Level1GB;
+  if (Page5LevelSupport && !Page1GSupport) {
+    PagingMode = Paging5Level;
+  } else if (!Page5LevelSupport && Page1GSupport) {
+    PagingMode = Paging4Level1GB;
+  } else if (!Page5LevelSupport && !Page1GSupport) {
+    PagingMode = Paging4Level;
+  }
+
+  DEBUG ((DEBUG_INFO, "MigratePageTable: PagingMode = 0x%lx\n", (UINTN) PagingMode));
+
+  //
+  // Get Maximum Physical Address Bits
+  // Get the number of address lines; Maximum Physical Address is 2^PhysicalAddressBits - 1.
+  // If CPUID does not supported, then use a max value of 36 as per SDM 3A, 4.1.4.
+  //
+  AsmCpuid (CPUID_EXTENDED_FUNCTION, &MaxExtendedFunctionId, NULL, NULL, NULL);
+  if (MaxExtendedFunctionId >= CPUID_VIR_PHY_ADDRESS_SIZE) {
+    AsmCpuid (CPUID_VIR_PHY_ADDRESS_SIZE, &VirPhyAddressSize.Uint32, NULL, NULL, NULL);
+  } else {
+    VirPhyAddressSize.Bits.PhysicalAddressBits = 36;
+  }
+
+  if (PagingMode == Paging4Level1GB || PagingMode == Paging4Level) {
+    //
+    // The max lineaddress bits is 48 for 4 level page table.
+    //
+    VirPhyAddressSize.Bits.PhysicalAddressBits = MIN (VirPhyAddressSize.Bits.PhysicalAddressBits, 48);
+  }
+
+  DEBUG ((DEBUG_INFO, "MigratePageTable: Maximum Physical Address Bits = %d\n", VirPhyAddressSize.Bits.PhysicalAddressBits));
+
+  //
+  // Get required buffer size for the pagetable that will be created.
+  //
+  Status = PageTableMap (&PageTable, PagingMode, 0, &BufferSize, 0, LShiftU64 (1, VirPhyAddressSize.Bits.PhysicalAddressBits), &MapAttribute, &MapMask, NULL);
+  ASSERT (Status == EFI_BUFFER_TOO_SMALL);
+  if (Status != EFI_BUFFER_TOO_SMALL) {
+    DEBUG ((DEBUG_ERROR, "MigratePageTable: Failed to get PageTable required BufferSize, Status = %r\n", Status));
+    return Status;
+  }
+
+  DEBUG ((DEBUG_INFO, "MigratePageTable: Get PageTable required BufferSize = %x\n", BufferSize));
+
+  //
+  // Allocate required Buffer.
+  //
+  Status = PeiServicesAllocatePages (
+             EfiBootServicesData,
+             EFI_SIZE_TO_PAGES (BufferSize),
+             &((EFI_PHYSICAL_ADDRESS) Buffer)
+             );
+  ASSERT (Buffer != NULL);
+  if (EFI_ERROR (Status)) {
+    DEBUG ((DEBUG_ERROR, "MigratePageTable: Failed to allocate PageTable required BufferSize, Status = %r\n", Status));
+    return EFI_OUT_OF_RESOURCES;
+  }
+
+  //
+  // Create PageTable in permanent memory.
+  //
+  Status = PageTableMap (&PageTable, PagingMode, Buffer, &BufferSize, 0, LShiftU64 (1, VirPhyAddressSize.Bits.PhysicalAddressBits), &MapAttribute, &MapMask, NULL);
+  ASSERT (!EFI_ERROR (Status) && PageTable != 0);
+  if (EFI_ERROR (Status) || PageTable == 0) {
+    DEBUG ((DEBUG_ERROR, "MigratePageTable: Failed to create PageTable, Status = %r, PageTable = 0x%lx\n", Status, PageTable));
+    return EFI_OUT_OF_RESOURCES;
+  }
+
+  DEBUG ((DEBUG_INFO, "MigratePageTable: Create PageTable = 0x%lx\n", PageTable));
+
+  //
+  // Write the Pagetable to CR3.
+  //
+  AsmWriteCr3 (PageTable);
+
+  DEBUG ((DEBUG_INFO, "MigratePageTable: Write the Pagetable to CR3 Sucessfully.\n"));
+
+  return Status;
+}
+
 //
 // These are IDT entries pointing to 10:FFFFFFE4h.
 //
 UINT64  mIdtEntryTemplate = 0xffff8e000010ffe4ULL;
 
@@ -492,10 +641,25 @@ SecTemporaryRamDone (
   if (PcdGetBool (PcdMigrateTemporaryRamFirmwareVolumes)) {
     Status = MigrateGdt ();
     ASSERT_EFI_ERROR (Status);
   }
 
+  //
+  // Migrate page table to permanent memory mapping entire physical address space if CR0.PG is set.
+  //
+  if ((AsmReadCr0 () & BIT31) != 0) {
+    //
+    // CR4.PAE must be enabled.
+    //
+    ASSERT ((AsmReadCr4 () & BIT5) != 0);
+    Status = MigratePageTable ();
+    if (EFI_ERROR (Status)) {
+      DEBUG ((DEBUG_WARN, "SecTemporaryRamDone: Failed to migrate page table to permanent memory: %r.\n", Status));
+      ASSERT_EFI_ERROR (Status);
+    }
+  }
+
   //
   // Disable Temporary RAM after Stack and Heap have been migrated at this point.
   //
   SecPlatformDisableTemporaryMemory ();
 
diff --git a/UefiCpuPkg/SecCore/SecMain.h b/UefiCpuPkg/SecCore/SecMain.h
index 880e6cd1b8..b50d96e45b 100644
--- a/UefiCpuPkg/SecCore/SecMain.h
+++ b/UefiCpuPkg/SecCore/SecMain.h
@@ -17,10 +17,11 @@
 #include <Ppi/PeiCoreFvLocation.h>
 #include <Ppi/RepublishSecPpi.h>
 
 #include <Guid/FirmwarePerformance.h>
 
+#include <Library/BaseLib.h>
 #include <Library/DebugLib.h>
 #include <Library/PcdLib.h>
 #include <Library/BaseMemoryLib.h>
 #include <Library/PlatformSecLib.h>
 #include <Library/CpuLib.h>
@@ -30,10 +31,13 @@
 #include <Library/CpuExceptionHandlerLib.h>
 #include <Library/ReportStatusCodeLib.h>
 #include <Library/PeiServicesTablePointerLib.h>
 #include <Library/HobLib.h>
 #include <Library/PeiServicesLib.h>
+#include <Library/CpuPageTableLib.h>
+#include <Register/Intel/Cpuid.h>
+#include <Register/Intel/Msr.h>
 
 #define SEC_IDT_ENTRY_COUNT  34
 
 typedef struct _SEC_IDT_TABLE {
   //
-- 
2.16.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104361): https://edk2.groups.io/g/devel/message/104361
Mute This Topic: https://groups.io/mt/98780500/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

> -----Original Message-----
> From: Wu, Jiaxin <jiaxin.wu@intel.com>
> Sent: Tuesday, May 9, 2023 6:23 PM
> To: devel@edk2.groups.io
> Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Zeng, Star
> <star.zeng@intel.com>; Gerd Hoffmann <kraxel@redhat.com>; Kumar, Rahul R
> <rahul.r.kumar@intel.com>
> Subject: [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate page table to permanent
> memory
> 
> Background:
> For arch X64, system will enable the page table in SPI to cover 0-512G range
> via CR4.PAE & MSR.LME & CR0.PG & CR3 setting (see ResetVector code).
> Existing
> code doesn't cover the higher address access above 512G before memory-
> discovered
> callback. That will be potential problem if system access the higher address
> after the transition from temporary RAM to permanent MEM RAM.
> 
> Solution:
> This patch is to migrate page table to permanent memory to map entire physical
> address space if CR0.PG is set during temporary RAM Done.
> 
> Change-Id: I29bdb078ef567ed9455d1328cb007f4f60a617a2

1. please remove Change-Id.

> +
> +  //
> +  // Check CPU runs in 64bit mode or 32bit mode
> +  //
> +  if (sizeof (UINTN) == sizeof (UINT32)) {
> +    DEBUG ((DEBUG_WARN, "MigratePageTable: CPU runs in 32bit mode,
> unsupport to migrate page table to permanent memory.\n"));

2. I am ok to assume that this function should not be called when CPU runs in 32bit mode because we
assume 32bit cpu doesn't enable paging in PEI at this moment.
Can you just add assert such as ASSERT (sizeof (UINTN) == sizeof (UINT64))?
The if check and debug messages can be removed.


> +  //
> +  // Check Page1G Support or not.
> +  //
> +  Page1GSupport = FALSE;
> +  AsmCpuid (CPUID_EXTENDED_FUNCTION, &RegEax, NULL, NULL, NULL);
> +  if (RegEax >= CPUID_EXTENDED_CPU_SIG) {
> +    AsmCpuid (CPUID_EXTENDED_CPU_SIG, NULL, NULL, NULL, &RegEdx);
> +    if ((RegEdx & BIT26) != 0) {

3. can you use the bitfield in above if-check instead of checking BIT26?

> +
> +  //
> +  // Decide Paging Mode according Page5LevelSupport & Page1GSupport.
> +  //
> +  PagingMode = Paging5Level1GB;
> +  if (Page5LevelSupport && !Page1GSupport) {
> +    PagingMode = Paging5Level;
> +  } else if (!Page5LevelSupport && Page1GSupport) {
> +    PagingMode = Paging4Level1GB;
> +  } else if (!Page5LevelSupport && !Page1GSupport) {
> +    PagingMode = Paging4Level;
> +  }

4. how about?
   if (Page5LevelSupport) {
      PagingMode = Page1GSupport? Paging5Level1GB: Paging5Level;
    } else {
      PagingMode = Page1GSupport? Paging4Level1GB: Paging4Level;
   }


> +
> +  DEBUG ((DEBUG_INFO, "MigratePageTable: PagingMode = 0x%lx\n", (UINTN)
> PagingMode));

5. There are lots of DEBUG() macro call in this patch. Can you think about how to merge them?
Basically if code between two DEBUG() calls is impossible to cause hang, you can combine the 1st
DEBUG() call into the 2nd.

> +
> +  //
> +  // Get Maximum Physical Address Bits
> +  // Get the number of address lines; Maximum Physical Address is
> 2^PhysicalAddressBits - 1.
> +  // If CPUID does not supported, then use a max value of 36 as per SDM 3A,
> 4.1.4.
> +  //
> +  AsmCpuid (CPUID_EXTENDED_FUNCTION, &MaxExtendedFunctionId, NULL,
> NULL, NULL);
> +  if (MaxExtendedFunctionId >= CPUID_VIR_PHY_ADDRESS_SIZE) {
> +    AsmCpuid (CPUID_VIR_PHY_ADDRESS_SIZE, &VirPhyAddressSize.Uint32,
> NULL, NULL, NULL);
> +  } else {
> +    VirPhyAddressSize.Bits.PhysicalAddressBits = 36;
> +  }
> +
> +  if (PagingMode == Paging4Level1GB || PagingMode == Paging4Level) {
> +    //
> +    // The max lineaddress bits is 48 for 4 level page table.
> +    //
> +    VirPhyAddressSize.Bits.PhysicalAddressBits = MIN
> (VirPhyAddressSize.Bits.PhysicalAddressBits, 48);
> +  }
> +
> +  DEBUG ((DEBUG_INFO, "MigratePageTable: Maximum Physical Address Bits
> = %d\n", VirPhyAddressSize.Bits.PhysicalAddressBits));
> +
> +  //
> +  // Get required buffer size for the pagetable that will be created.
> +  //
> +  Status = PageTableMap (&PageTable, PagingMode, 0, &BufferSize, 0,
> LShiftU64 (1, VirPhyAddressSize.Bits.PhysicalAddressBits), &MapAttribute,
> &MapMask, NULL);
> +  ASSERT (Status == EFI_BUFFER_TOO_SMALL);
> +  if (Status != EFI_BUFFER_TOO_SMALL) {
> +    DEBUG ((DEBUG_ERROR, "MigratePageTable: Failed to get PageTable
> required BufferSize, Status = %r\n", Status));

6. I think ASSERT() is enough. No need for a debug message.

> +    return Status;
> +  }
> +
> +  DEBUG ((DEBUG_INFO, "MigratePageTable: Get PageTable required
> BufferSize = %x\n", BufferSize));
> +
> +  //
> +  // Allocate required Buffer.
> +  //
> +  Status = PeiServicesAllocatePages (
> +             EfiBootServicesData,
> +             EFI_SIZE_TO_PAGES (BufferSize),
> +             &((EFI_PHYSICAL_ADDRESS) Buffer)
> +             );
> +  ASSERT (Buffer != NULL);
> +  if (EFI_ERROR (Status)) {
> +    DEBUG ((DEBUG_ERROR, "MigratePageTable: Failed to allocate PageTable
> required BufferSize, Status = %r\n", Status));
> +    return EFI_OUT_OF_RESOURCES;
> +  }
> +
> +  //
> +  // Create PageTable in permanent memory.
> +  //
> +  Status = PageTableMap (&PageTable, PagingMode, Buffer, &BufferSize, 0,
> LShiftU64 (1, VirPhyAddressSize.Bits.PhysicalAddressBits), &MapAttribute,
> &MapMask, NULL);
> +  ASSERT (!EFI_ERROR (Status) && PageTable != 0);
> +  if (EFI_ERROR (Status) || PageTable == 0) {
> +    DEBUG ((DEBUG_ERROR, "MigratePageTable: Failed to create PageTable,
> Status = %r, PageTable = 0x%lx\n", Status, PageTable));
> +    return EFI_OUT_OF_RESOURCES;
> +  }
> +
> +  DEBUG ((DEBUG_INFO, "MigratePageTable: Create PageTable = 0x%lx\n",
> PageTable));
> +
> +  //
> +  // Write the Pagetable to CR3.
> +  //
> +  AsmWriteCr3 (PageTable);
> +
> +  DEBUG ((DEBUG_INFO, "MigratePageTable: Write the Pagetable to CR3
> Sucessfully.\n"));
> +
> +  return Status;
> +}
> +
>  //
>  // These are IDT entries pointing to 10:FFFFFFE4h.
>  //
>  UINT64  mIdtEntryTemplate = 0xffff8e000010ffe4ULL;
> 
> @@ -492,10 +641,25 @@ SecTemporaryRamDone (
>    if (PcdGetBool (PcdMigrateTemporaryRamFirmwareVolumes)) {
>      Status = MigrateGdt ();
>      ASSERT_EFI_ERROR (Status);
>    }
> 
> +  //
> +  // Migrate page table to permanent memory mapping entire physical address
> space if CR0.PG is set.
> +  //
> +  if ((AsmReadCr0 () & BIT31) != 0) {

7. Can you use IA32_CR0 structure in if-check?

8. can you please add ASSERT (sizeof (UINTN) == sizeof (UINT32)) before calling MigratePageTable()?

> +    //
> +    // CR4.PAE must be enabled.
> +    //
> +    ASSERT ((AsmReadCr4 () & BIT5) != 0);
> +    Status = MigratePageTable ();
> +    if (EFI_ERROR (Status)) {
> +      DEBUG ((DEBUG_WARN, "SecTemporaryRamDone: Failed to migrate page
> table to permanent memory: %r.\n", Status));
> +      ASSERT_EFI_ERROR (Status);
> +    }
> +  }
> +
>    //
>    // Disable Temporary RAM after Stack and Heap have been migrated at this
> point.
>    //
>    SecPlatformDisableTemporaryMemory ();
> 
> diff --git a/UefiCpuPkg/SecCore/SecMain.h b/UefiCpuPkg/SecCore/SecMain.h
> index 880e6cd1b8..b50d96e45b 100644
> --- a/UefiCpuPkg/SecCore/SecMain.h
> +++ b/UefiCpuPkg/SecCore/SecMain.h
> @@ -17,10 +17,11 @@
>  #include <Ppi/PeiCoreFvLocation.h>
>  #include <Ppi/RepublishSecPpi.h>
> 
>  #include <Guid/FirmwarePerformance.h>
> 
> +#include <Library/BaseLib.h>
>  #include <Library/DebugLib.h>
>  #include <Library/PcdLib.h>
>  #include <Library/BaseMemoryLib.h>
>  #include <Library/PlatformSecLib.h>
>  #include <Library/CpuLib.h>
> @@ -30,10 +31,13 @@
>  #include <Library/CpuExceptionHandlerLib.h>
>  #include <Library/ReportStatusCodeLib.h>
>  #include <Library/PeiServicesTablePointerLib.h>
>  #include <Library/HobLib.h>
>  #include <Library/PeiServicesLib.h>
> +#include <Library/CpuPageTableLib.h>
> +#include <Register/Intel/Cpuid.h>
> +#include <Register/Intel/Msr.h>
> 
>  #define SEC_IDT_ENTRY_COUNT  34
> 
>  typedef struct _SEC_IDT_TABLE {
>    //
> --
> 2.16.2.windows.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104505): https://edk2.groups.io/g/devel/message/104505
Mute This Topic: https://groups.io/mt/98780500/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

  Hi,

> +  if (PagingMode == Paging4Level1GB || PagingMode == Paging4Level) {
> +    //
> +    // The max lineaddress bits is 48 for 4 level page table.
> +    //
> +    VirPhyAddressSize.Bits.PhysicalAddressBits = MIN (VirPhyAddressSize.Bits.PhysicalAddressBits, 48);
> +  }

virtual addresses in long mode are sign-extended.  Which means you have
only 47 bits (or 56 bits with 5-level paging) for identity mappings.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104381): https://edk2.groups.io/g/devel/message/104381
Mute This Topic: https://groups.io/mt/98780500/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

Gerd,
My understanding is that when code dereferences memory address, the code itself is responsible for
supplying the sign-extended linear address.
The page table creation logic still maps the entire linear memory space supported by the CPU.

Why do you think covering the half of the space is better?

Thanks,
Ray

> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Gerd
> Hoffmann
> Sent: Tuesday, May 9, 2023 10:39 PM
> To: devel@edk2.groups.io; Wu, Jiaxin <jiaxin.wu@intel.com>
> Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Zeng, Star
> <star.zeng@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>
> Subject: Re: [edk2-devel] [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate page
> table to permanent memory
> 
>   Hi,
> 
> > +  if (PagingMode == Paging4Level1GB || PagingMode == Paging4Level) {
> > +    //
> > +    // The max lineaddress bits is 48 for 4 level page table.
> > +    //
> > +    VirPhyAddressSize.Bits.PhysicalAddressBits = MIN
> (VirPhyAddressSize.Bits.PhysicalAddressBits, 48);
> > +  }
> 
> virtual addresses in long mode are sign-extended.  Which means you have
> only 47 bits (or 56 bits with 5-level paging) for identity mappings.
> 
> take care,
>   Gerd
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104476): https://edk2.groups.io/g/devel/message/104476
Mute This Topic: https://groups.io/mt/98780500/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

On Wed, May 10, 2023 at 02:48:52AM +0000, Ni, Ray wrote:
> Gerd,
> My understanding is that when code dereferences memory address, the code itself is responsible for
> supplying the sign-extended linear address.
> The page table creation logic still maps the entire linear memory space supported by the CPU.
> 
> Why do you think covering the half of the space is better?

edk2 boot services operate on the assumption that everything is identity
mapped, only runtime services know the concept of virtual addresses.

The lower half of the address space can be identity-mapped (virtual
address == physical address).  The upper half can not, so I think it's
better for efi boot services to restrict themself to the lower half.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104504): https://edk2.groups.io/g/devel/message/104504
Mute This Topic: https://groups.io/mt/98780500/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

> -----Original Message-----
> From: kraxel@redhat.com <kraxel@redhat.com>
> Sent: Wednesday, May 10, 2023 3:48 PM
> To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>
> Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Dong, Eric <eric.dong@intel.com>; Zeng,
> Star <star.zeng@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>
> Subject: Re: [edk2-devel] [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate page
> table to permanent memory
> 
> On Wed, May 10, 2023 at 02:48:52AM +0000, Ni, Ray wrote:
> > Gerd,
> > My understanding is that when code dereferences memory address, the code
> itself is responsible for
> > supplying the sign-extended linear address.
> > The page table creation logic still maps the entire linear memory space
> supported by the CPU.
> >
> > Why do you think covering the half of the space is better?
> 
> edk2 boot services operate on the assumption that everything is identity
> mapped, only runtime services know the concept of virtual addresses.
> 
> The lower half of the address space can be identity-mapped (virtual
> address == physical address).  The upper half can not, so I think it's
> better for efi boot services to restrict themself to the lower half.

Good point. I am convinced that 4-level paging only maps up to 2^47 address and
5-level only maps up to 2^56 address.

+@Kinney, Michael D, if he have other thoughts.

> 
> take care,
>   Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104668): https://edk2.groups.io/g/devel/message/104668
Mute This Topic: https://groups.io/mt/98780500/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

What's your comments to the existing code logic for the PhysicalAddressBits in the CreateIdentityMappingPageTables()? Looks all doesn't consider the  sign-extended case? is it reasonable create the paging but not used? All system with long mode are sign-extended?

//
  // IA-32e paging translates 48-bit linear addresses to 52-bit physical addresses
  //  when 5-Level Paging is disabled,
  //  due to either unsupported by HW, or disabled by PCD.
  //
  ASSERT (PhysicalAddressBits <= 52);
  if (!Page5LevelSupport && (PhysicalAddressBits > 48)) {
    PhysicalAddressBits = 48;
  }


> -----Original Message-----
> From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Gerd
> Hoffmann
> Sent: Wednesday, May 10, 2023 3:48 PM
> To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>
> Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Dong, Eric <eric.dong@intel.com>; Zeng,
> Star <star.zeng@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>
> Subject: Re: [edk2-devel] [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate page
> table to permanent memory
> 
> On Wed, May 10, 2023 at 02:48:52AM +0000, Ni, Ray wrote:
> > Gerd,
> > My understanding is that when code dereferences memory address, the code
> itself is responsible for
> > supplying the sign-extended linear address.
> > The page table creation logic still maps the entire linear memory space
> supported by the CPU.
> >
> > Why do you think covering the half of the space is better?
> 
> edk2 boot services operate on the assumption that everything is identity
> mapped, only runtime services know the concept of virtual addresses.
> 
> The lower half of the address space can be identity-mapped (virtual
> address == physical address).  The upper half can not, so I think it's
> better for efi boot services to restrict themself to the lower half.
> 
> take care,
>   Gerd
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104667): https://edk2.groups.io/g/devel/message/104667
Mute This Topic: https://groups.io/mt/98780500/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

Jiaxin,
Let's keep using 48 or 57.
We can use separate patch to clean all existing code to use 47 and 56.

Thanks,
Ray

> -----Original Message-----
> From: Wu, Jiaxin <jiaxin.wu@intel.com>
> Sent: Thursday, May 11, 2023 1:08 PM
> To: devel@edk2.groups.io; kraxel@redhat.com; Ni, Ray <ray.ni@intel.com>
> Cc: Dong, Eric <eric.dong@intel.com>; Zeng, Star <star.zeng@intel.com>;
> Kumar, Rahul R <rahul.r.kumar@intel.com>
> Subject: RE: [edk2-devel] [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate page
> table to permanent memory
> 
> What's your comments to the existing code logic for the PhysicalAddressBits in
> the CreateIdentityMappingPageTables()? Looks all doesn't consider the  sign-
> extended case? is it reasonable create the paging but not used? All system with
> long mode are sign-extended?
> 
> //
>   // IA-32e paging translates 48-bit linear addresses to 52-bit physical addresses
>   //  when 5-Level Paging is disabled,
>   //  due to either unsupported by HW, or disabled by PCD.
>   //
>   ASSERT (PhysicalAddressBits <= 52);
>   if (!Page5LevelSupport && (PhysicalAddressBits > 48)) {
>     PhysicalAddressBits = 48;
>   }
> 
> 
> > -----Original Message-----
> > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Gerd
> > Hoffmann
> > Sent: Wednesday, May 10, 2023 3:48 PM
> > To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>
> > Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Dong, Eric <eric.dong@intel.com>;
> Zeng,
> > Star <star.zeng@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>
> > Subject: Re: [edk2-devel] [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate page
> > table to permanent memory
> >
> > On Wed, May 10, 2023 at 02:48:52AM +0000, Ni, Ray wrote:
> > > Gerd,
> > > My understanding is that when code dereferences memory address, the code
> > itself is responsible for
> > > supplying the sign-extended linear address.
> > > The page table creation logic still maps the entire linear memory space
> > supported by the CPU.
> > >
> > > Why do you think covering the half of the space is better?
> >
> > edk2 boot services operate on the assumption that everything is identity
> > mapped, only runtime services know the concept of virtual addresses.
> >
> > The lower half of the address space can be identity-mapped (virtual
> > address == physical address).  The upper half can not, so I think it's
> > better for efi boot services to restrict themself to the lower half.
> >
> > take care,
> >   Gerd
> >
> >
> >
> > 
> >



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104682): https://edk2.groups.io/g/devel/message/104682
Mute This Topic: https://groups.io/mt/98780500/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

Agree, thanks comments.

> -----Original Message-----
> From: Ni, Ray <ray.ni@intel.com>
> Sent: Thursday, May 11, 2023 3:48 PM
> To: Wu, Jiaxin <jiaxin.wu@intel.com>; devel@edk2.groups.io;
> kraxel@redhat.com
> Cc: Dong, Eric <eric.dong@intel.com>; Zeng, Star <star.zeng@intel.com>;
> Kumar, Rahul R <rahul.r.kumar@intel.com>
> Subject: RE: [edk2-devel] [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate page
> table to permanent memory
> 
> Jiaxin,
> Let's keep using 48 or 57.
> We can use separate patch to clean all existing code to use 47 and 56.
> 
> Thanks,
> Ray
> 
> > -----Original Message-----
> > From: Wu, Jiaxin <jiaxin.wu@intel.com>
> > Sent: Thursday, May 11, 2023 1:08 PM
> > To: devel@edk2.groups.io; kraxel@redhat.com; Ni, Ray <ray.ni@intel.com>
> > Cc: Dong, Eric <eric.dong@intel.com>; Zeng, Star <star.zeng@intel.com>;
> > Kumar, Rahul R <rahul.r.kumar@intel.com>
> > Subject: RE: [edk2-devel] [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate page
> > table to permanent memory
> >
> > What's your comments to the existing code logic for the PhysicalAddressBits
> in
> > the CreateIdentityMappingPageTables()? Looks all doesn't consider the  sign-
> > extended case? is it reasonable create the paging but not used? All system
> with
> > long mode are sign-extended?
> >
> > //
> >   // IA-32e paging translates 48-bit linear addresses to 52-bit physical
> addresses
> >   //  when 5-Level Paging is disabled,
> >   //  due to either unsupported by HW, or disabled by PCD.
> >   //
> >   ASSERT (PhysicalAddressBits <= 52);
> >   if (!Page5LevelSupport && (PhysicalAddressBits > 48)) {
> >     PhysicalAddressBits = 48;
> >   }
> >
> >
> > > -----Original Message-----
> > > From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Gerd
> > > Hoffmann
> > > Sent: Wednesday, May 10, 2023 3:48 PM
> > > To: devel@edk2.groups.io; Ni, Ray <ray.ni@intel.com>
> > > Cc: Wu, Jiaxin <jiaxin.wu@intel.com>; Dong, Eric <eric.dong@intel.com>;
> > Zeng,
> > > Star <star.zeng@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>
> > > Subject: Re: [edk2-devel] [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate
> page
> > > table to permanent memory
> > >
> > > On Wed, May 10, 2023 at 02:48:52AM +0000, Ni, Ray wrote:
> > > > Gerd,
> > > > My understanding is that when code dereferences memory address, the
> code
> > > itself is responsible for
> > > > supplying the sign-extended linear address.
> > > > The page table creation logic still maps the entire linear memory space
> > > supported by the CPU.
> > > >
> > > > Why do you think covering the half of the space is better?
> > >
> > > edk2 boot services operate on the assumption that everything is identity
> > > mapped, only runtime services know the concept of virtual addresses.
> > >
> > > The lower half of the address space can be identity-mapped (virtual
> > > address == physical address).  The upper half can not, so I think it's
> > > better for efi boot services to restrict themself to the lower half.
> > >
> > > take care,
> > >   Gerd
> > >
> > >
> > >
> > > 
> > >



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104735): https://edk2.groups.io/g/devel/message/104735
Mute This Topic: https://groups.io/mt/98780500/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

Hi Gerd,

Could you share me which document introduce the sign-extended impact the line address width?

Thanks,
Jiaxin 

> -----Original Message-----
> From: Gerd Hoffmann <kraxel@redhat.com>
> Sent: Tuesday, May 9, 2023 10:39 PM
> To: devel@edk2.groups.io; Wu, Jiaxin <jiaxin.wu@intel.com>
> Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Zeng, Star
> <star.zeng@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>
> Subject: Re: [edk2-devel] [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate page
> table to permanent memory
> 
>   Hi,
> 
> > +  if (PagingMode == Paging4Level1GB || PagingMode == Paging4Level) {
> > +    //
> > +    // The max lineaddress bits is 48 for 4 level page table.
> > +    //
> > +    VirPhyAddressSize.Bits.PhysicalAddressBits = MIN
> (VirPhyAddressSize.Bits.PhysicalAddressBits, 48);
> > +  }
> 
> virtual addresses in long mode are sign-extended.  Which means you have
> only 47 bits (or 56 bits with 5-level paging) for identity mappings.
> 
> take care,
>   Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104464): https://edk2.groups.io/g/devel/message/104464
Mute This Topic: https://groups.io/mt/98780500/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

Jiaxin,
SDM has following:
> 3.3.7.1 Canonical Addressing
> In 64-bit mode, an address is considered to be in canonical form if **address bits 63 through to the most-significant implemented bit by the microarchitecture are set to either all ones or all zeros**.
> Intel 64 architecture defines a 64-bit linear address. Implementations can support less. The first implementation of IA-32 processors with Intel 64 architecture supports a 48-bit linear address. This means a canonical address must have bits 63 through 48 set to zeros or ones (depending on whether bit 47 is a zero or one).
> Although implementations may not use all 64 bits of the linear address, they should check bits 63 through the most-significant implemented bit to see if the address is in canonical form. If a linear-memory reference is not in canonical form, the implementation should generate an exception. In most cases, a general-protection exception (#GP) is generated.

> -----Original Message-----
> From: Wu, Jiaxin <jiaxin.wu@intel.com>
> Sent: Wednesday, May 10, 2023 10:00 AM
> To: Gerd Hoffmann <kraxel@redhat.com>; devel@edk2.groups.io
> Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Zeng, Star
> <star.zeng@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>
> Subject: RE: [edk2-devel] [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate page
> table to permanent memory
> 
> Hi Gerd,
> 
> Could you share me which document introduce the sign-extended impact the
> line address width?
> 
> Thanks,
> Jiaxin
> 
> > -----Original Message-----
> > From: Gerd Hoffmann <kraxel@redhat.com>
> > Sent: Tuesday, May 9, 2023 10:39 PM
> > To: devel@edk2.groups.io; Wu, Jiaxin <jiaxin.wu@intel.com>
> > Cc: Dong, Eric <eric.dong@intel.com>; Ni, Ray <ray.ni@intel.com>; Zeng, Star
> > <star.zeng@intel.com>; Kumar, Rahul R <rahul.r.kumar@intel.com>
> > Subject: Re: [edk2-devel] [PATCH v1 1/3] UefiCpuPkg/SecCore: Migrate page
> > table to permanent memory
> >
> >   Hi,
> >
> > > +  if (PagingMode == Paging4Level1GB || PagingMode == Paging4Level) {
> > > +    //
> > > +    // The max lineaddress bits is 48 for 4 level page table.
> > > +    //
> > > +    VirPhyAddressSize.Bits.PhysicalAddressBits = MIN
> > (VirPhyAddressSize.Bits.PhysicalAddressBits, 48);
> > > +  }
> >
> > virtual addresses in long mode are sign-extended.  Which means you have
> > only 47 bits (or 56 bits with 5-level paging) for identity mappings.
> >
> > take care,
> >   Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#104475): https://edk2.groups.io/g/devel/message/104475
Mute This Topic: https://groups.io/mt/98780500/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-