[PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary

[PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary

[Boeuf, Sebastien]

From: Sebastien Boeuf <sebastien.boeuf@intel.com>

Following the model from the Xen target, CloudHv is generated as a PVH
ELF binary to take advantage of the PVH specification.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
---
 OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c | 150 ++++++++++++++++++++
 OvmfPkg/CloudHv/CloudHvX64.dsc              |   2 +-
 OvmfPkg/CloudHv/CloudHvX64.fdf              |  92 +++++++++++-
 3 files changed, 241 insertions(+), 3 deletions(-)
 create mode 100644 OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c

diff --git a/OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c b/OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c
new file mode 100644
index 0000000000..83f4e37147
--- /dev/null
+++ b/OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c
@@ -0,0 +1,150 @@
+/** @file
+  This program generates a hex array to be manually coppied into
+  OvmfXen.fdf.
+
+  The purpose is for the flash device image to be recognize as an ELF.
+
+  Copyright (c) 2019, Citrix Systems, Inc.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include "elf.h"
+#include "stdio.h"
+#include "stddef.h"
+
+void
+print_hdr (
+  void    *s,
+  size_t  size
+  )
+{
+  char  *c = s;
+
+  while (size--) {
+    printf ("0x%02hhx, ", *(c++));
+  }
+}
+
+/* Format for the XEN_ELFNOTE_PHYS32_ENTRY program segment */
+#define XEN_ELFNOTE_PHYS32_ENTRY  18
+typedef struct {
+  uint32_t    name_size;
+  uint32_t    desc_size;
+  uint32_t    type;
+  char        name[4];
+  uint32_t    desc;
+} xen_elfnote_phys32_entry;
+
+int
+main (
+  void
+  )
+{
+  /* FW_SIZE */
+  size_t  ovmf_blob_size = 0x00400000;
+  /* Load OVMF at 1MB when running as PVH guest */
+  uint32_t  ovmf_base_address = 0x00100000;
+  /* Xen PVH entry point */
+  uint32_t  ovmfxen_pvh_entry_point = ovmf_base_address + ovmf_blob_size - 0x30;
+  size_t    offset_into_file        = 0;
+
+  /* ELF file header */
+  Elf64_Ehdr  hdr = {
+    .e_ident     = ELFMAG,
+    .e_type      = ET_EXEC,
+    .e_machine   = EM_386,
+    .e_version   = EV_CURRENT,
+    .e_entry     = ovmfxen_pvh_entry_point,
+    .e_flags     = R_386_NONE,
+    .e_ehsize    = sizeof (hdr),
+    .e_phentsize = sizeof (Elf64_Phdr),
+  };
+
+  offset_into_file += sizeof (hdr);
+
+  hdr.e_ident[EI_CLASS]   = ELFCLASS64;
+  hdr.e_ident[EI_DATA]    = ELFDATA2LSB;
+  hdr.e_ident[EI_VERSION] = EV_CURRENT;
+  hdr.e_ident[EI_OSABI]   = ELFOSABI_LINUX;
+  /* Placing program headers just after hdr */
+  hdr.e_phoff = sizeof (hdr);
+
+  /* program header */
+  Elf64_Phdr  phdr_load = {
+    .p_type   = PT_LOAD,
+    .p_offset = 0, /* load everything */
+    .p_paddr  = ovmf_base_address,
+    .p_filesz = ovmf_blob_size,
+    .p_memsz  = ovmf_blob_size,
+    .p_flags  = PF_X | PF_W | PF_R,
+    .p_align  = 4,
+  };
+
+  phdr_load.p_vaddr = phdr_load.p_paddr;
+  hdr.e_phnum      += 1;
+  offset_into_file += sizeof (phdr_load);
+
+  /* Xen ELF Note. */
+
+  xen_elfnote_phys32_entry  xen_elf_note = {
+    .type      = XEN_ELFNOTE_PHYS32_ENTRY,
+    .name      = "Xen",
+    .desc      = ovmfxen_pvh_entry_point,
+    .name_size =
+      offsetof (xen_elfnote_phys32_entry, desc) -
+      offsetof (xen_elfnote_phys32_entry, name),
+    .desc_size =
+      sizeof (xen_elfnote_phys32_entry) -
+      offsetof (xen_elfnote_phys32_entry, desc),
+  };
+  Elf64_Phdr                phdr_note = {
+    .p_type   = PT_NOTE,
+    .p_filesz = sizeof (xen_elf_note),
+    .p_memsz  = sizeof (xen_elf_note),
+    .p_flags  = PF_R,
+    .p_align  = 4,
+  };
+
+  hdr.e_phnum       += 1;
+  offset_into_file  += sizeof (phdr_note);
+  phdr_note.p_offset = offset_into_file;
+  phdr_note.p_paddr  = ovmf_base_address + phdr_note.p_offset;
+  phdr_note.p_vaddr  = phdr_note.p_paddr;
+
+  /*
+   * print elf header
+   */
+
+  size_t  i;
+  size_t  hdr_size  = sizeof (hdr);
+  size_t  entry_off = offsetof (typeof(hdr), e_entry);
+
+  printf ("# ELF file header\n");
+  print_hdr (&hdr, entry_off);
+  printf ("\n");
+  print_hdr (&hdr.e_entry, sizeof (hdr.e_entry));
+  printf (" # hdr.e_entry\n");
+  print_hdr (&hdr.e_entry + 1, hdr_size - entry_off - sizeof (hdr.e_entry));
+
+  printf ("\n\n# ELF Program segment headers\n");
+  printf ("# - Load segment\n");
+  for (i = 0; i < sizeof (phdr_load); i += 4) {
+    print_hdr (((char *)&phdr_load) + i, 4);
+    printf ("\n");
+  }
+
+  printf ("# - ELFNOTE segment\n");
+  for (i = 0; i < sizeof (phdr_note); i += 4) {
+    print_hdr (((char *)&phdr_note) + i, 4);
+    printf ("\n");
+  }
+
+  printf ("\n# XEN_ELFNOTE_PHYS32_ENTRY\n");
+  for (i = 0; i < sizeof (xen_elf_note); i += 4) {
+    print_hdr (((char *)&xen_elf_note) + i, 4);
+    printf ("\n");
+  }
+
+  return 0;
+}
diff --git a/OvmfPkg/CloudHv/CloudHvX64.dsc b/OvmfPkg/CloudHv/CloudHvX64.dsc
index 3172100310..b4d855d80f 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.dsc
+++ b/OvmfPkg/CloudHv/CloudHvX64.dsc
@@ -631,7 +631,7 @@
 #
 ################################################################################
 [Components]
-  OvmfPkg/ResetVector/ResetVector.inf
+  OvmfPkg/XenResetVector/XenResetVector.inf
 
   #
   # SEC Phase modules
diff --git a/OvmfPkg/CloudHv/CloudHvX64.fdf b/OvmfPkg/CloudHv/CloudHvX64.fdf
index ce3302c6d6..bb734d4c8d 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.fdf
+++ b/OvmfPkg/CloudHv/CloudHvX64.fdf
@@ -24,7 +24,95 @@ ErasePolarity = 1
 BlockSize     = $(BLOCK_SIZE)
 NumBlocks     = $(FW_BLOCKS)
 
-!include OvmfPkg/VarStore.fdf.inc
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x00000000|0x0000e000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00000000|0x00040000
+!endif
+DATA = {
+  #
+  # This hex array have been generated by OvmfPkg/OvmfXenElfHeaderGenerator.c
+  # and copied manually.
+  #
+  # ELF file header
+  0x7f, 0x45, 0x4c, 0x46, 0x02, 0x01, 0x01, 0x03, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x02, 0x00, 0x03, 0x00, 0x01, 0x00, 0x00, 0x00,
+  0xd0, 0xff, 0x4f, 0x00, 0x00, 0x00, 0x00, 0x00,  # hdr.e_entry
+  0x40, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x00, 0x38, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+
+  # ELF Program segment headers
+  # - Load segment
+  0x01, 0x00, 0x00, 0x00,
+  0x07, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x40, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x40, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x04, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  # - ELFNOTE segment
+  0x04, 0x00, 0x00, 0x00,
+  0x04, 0x00, 0x00, 0x00,
+  0xb0, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0xb0, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0xb0, 0x00, 0x10, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x14, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x14, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+  0x04, 0x00, 0x00, 0x00,
+  0x00, 0x00, 0x00, 0x00,
+
+  # XEN_ELFNOTE_PHYS32_ENTRY
+  0x04, 0x00, 0x00, 0x00,
+  0x04, 0x00, 0x00, 0x00,
+  0x12, 0x00, 0x00, 0x00,
+  0x58, 0x65, 0x6e, 0x00,
+  0xd0, 0xff, 0x4f, 0x00
+}
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x0000e000|0x00001000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00040000|0x00001000
+!endif
+#NV_EVENT_LOG
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x0000f000|0x00001000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00041000|0x00001000
+!endif
+#NV_FTW_WORKING
+DATA = {
+  # EFI_FAULT_TOLERANT_WORKING_BLOCK_HEADER->Signature = gEdkiiWorkingBlockSignatureGuid         =
+  #  { 0x9e58292b, 0x7c68, 0x497d, { 0xa0, 0xce, 0x65,  0x0, 0xfd, 0x9f, 0x1b, 0x95 }}
+  0x2b, 0x29, 0x58, 0x9e, 0x68, 0x7c, 0x7d, 0x49,
+  0xa0, 0xce, 0x65,  0x0, 0xfd, 0x9f, 0x1b, 0x95,
+  # Crc:UINT32            #WorkingBlockValid:1, WorkingBlockInvalid:1, Reserved
+  0x2c, 0xaf, 0x2c, 0x64, 0xFE, 0xFF, 0xFF, 0xFF,
+  # WriteQueueSize: UINT64
+  0xE0, 0x0F, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
+}
+
+!if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048)
+0x00010000|0x00010000
+!endif
+!if $(FD_SIZE_IN_KB) == 4096
+0x00042000|0x00042000
+!endif
+#NV_FTW_SPARE
 
 $(VARS_SIZE)|$(FVMAIN_SIZE)
 FV = FVMAIN_COMPACT
@@ -142,7 +230,7 @@ READ_LOCK_STATUS   = TRUE
 #
 INF  OvmfPkg/Sec/SecMain.inf
 
-INF  RuleOverride=RESET_VECTOR OvmfPkg/ResetVector/ResetVector.inf
+INF  RuleOverride=RESET_VECTOR OvmfPkg/XenResetVector/XenResetVector.inf
 
 ################################################################################
 [FV.PEIFV]
-- 
2.32.0

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[PATCH 2/3] OvmfPkg: CloudHv: Retrieve RSDP address from PVH

[Boeuf, Sebastien]

From: Sebastien Boeuf <sebastien.boeuf@intel.com>

Instead of hardcoding the address of the RSDP in the firmware, let's
rely on the PVH structure hvm_start_info to retrieve this information.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
---
 OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf |  2 ++
 OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c       | 39 ++++++++++++++-------
 OvmfPkg/CloudHv/CloudHvX64.fdf              |  3 ++
 OvmfPkg/Include/IndustryStandard/CloudHv.h  |  5 ---
 4 files changed, 32 insertions(+), 17 deletions(-)

diff --git a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
index b36b8413e0..f22bd7cb6d 100644
--- a/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
+++ b/OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf
@@ -56,6 +56,8 @@
 [Pcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdPciDisableBusEnumeration
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize
 
 [Depex]
   gEfiAcpiTableProtocolGuid
diff --git a/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c b/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
index 44a6bb70fe..ff59600d3e 100644
--- a/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
+++ b/OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c
@@ -7,9 +7,11 @@
 
 **/
 
-#include <IndustryStandard/CloudHv.h> // CLOUDHV_RSDP_ADDRESS
-#include <Library/BaseLib.h>          // CpuDeadLoop()
-#include <Library/DebugLib.h>         // DEBUG()
+#include <IndustryStandard/CloudHv.h>                     // CLOUDHV_RSDP_ADDRESS
+#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h> // hvm_start_info
+#include <Library/BaseLib.h>                              // CpuDeadLoop()
+#include <Library/DebugLib.h>                             // DEBUG()
+#include <Library/PcdLib.h>                               // PcdGet32()
 
 #include "AcpiPlatform.h"
 
@@ -23,20 +25,33 @@ InstallCloudHvTables (
   EFI_STATUS  Status;
   UINTN       TableHandle;
 
-  EFI_ACPI_DESCRIPTION_HEADER                *Xsdt;
-  VOID                                       *CurrentTableEntry;
-  UINTN                                      CurrentTablePointer;
-  EFI_ACPI_DESCRIPTION_HEADER                *CurrentTable;
-  UINTN                                      Index;
-  UINTN                                      NumberOfTableEntries;
-  EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE  *Fadt2Table;
-  EFI_ACPI_DESCRIPTION_HEADER                *DsdtTable;
+  EFI_ACPI_DESCRIPTION_HEADER                   *Xsdt;
+  VOID                                          *CurrentTableEntry;
+  UINTN                                         CurrentTablePointer;
+  EFI_ACPI_DESCRIPTION_HEADER                   *CurrentTable;
+  UINTN                                         Index;
+  UINTN                                         NumberOfTableEntries;
+  EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE     *Fadt2Table;
+  EFI_ACPI_DESCRIPTION_HEADER                   *DsdtTable;
+  EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER  *AcpiRsdpStructurePtr;
+  UINT32                                        *PVHResetVectorData;
+  struct hvm_start_info                         *pvh_start_info;
 
   Fadt2Table           = NULL;
   DsdtTable            = NULL;
   TableHandle          = 0;
   NumberOfTableEntries = 0;
-  EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER  *AcpiRsdpStructurePtr = (VOID *)CLOUDHV_RSDP_ADDRESS;
+  AcpiRsdpStructurePtr = NULL;
+  PVHResetVectorData   = NULL;
+  pvh_start_info       = NULL;
+
+  PVHResetVectorData = (VOID *)(UINTN)PcdGet32 (PcdXenPvhStartOfDayStructPtr);
+  if (PVHResetVectorData == 0) {
+    return EFI_NOT_FOUND;
+  }
+
+  pvh_start_info       = (struct hvm_start_info *)(UINTN)PVHResetVectorData[0];
+  AcpiRsdpStructurePtr = (EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *)(UINTN)pvh_start_info->rsdp_paddr;
 
   // If XSDT table is found, just install its tables.
   // Otherwise, try to find and install the RSDT tables.
diff --git a/OvmfPkg/CloudHv/CloudHvX64.fdf b/OvmfPkg/CloudHv/CloudHvX64.fdf
index bb734d4c8d..c9620526d5 100644
--- a/OvmfPkg/CloudHv/CloudHvX64.fdf
+++ b/OvmfPkg/CloudHv/CloudHvX64.fdf
@@ -182,6 +182,9 @@ gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSnpSecretsBase|gUefiOvmfPkgTokenSpaceGuid.PcdO
 0x00E000|0x001000
 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfCpuidSize
 
+0x00F000|0x001000
+gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr|gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize
+
 0x010000|0x010000
 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
 
diff --git a/OvmfPkg/Include/IndustryStandard/CloudHv.h b/OvmfPkg/Include/IndustryStandard/CloudHv.h
index 86404cc97e..d31ecc9eec 100644
--- a/OvmfPkg/Include/IndustryStandard/CloudHv.h
+++ b/OvmfPkg/Include/IndustryStandard/CloudHv.h
@@ -38,9 +38,4 @@
 //
 #define CLOUDHV_SMBIOS_ADDRESS  0xf0000
 
-//
-// RSDP address
-//
-#define CLOUDHV_RSDP_ADDRESS  0xa0000
-
 #endif // __CLOUDHV_H__
-- 
2.32.0

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[PATCH 3/3] OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS

[Boeuf, Sebastien]

From: Sebastien Boeuf <sebastien.boeuf@intel.com>

Instead of using the CMOS, the CloudHv platform relies on the list of
memmap entries provided through the PVH boot protocol to determine the
last RAM address below 4G.

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
---
 OvmfPkg/PlatformPei/MemDetect.c     | 73 +++++++++++++++++++++++++++++
 OvmfPkg/PlatformPei/PlatformPei.inf |  2 +
 2 files changed, 75 insertions(+)

diff --git a/OvmfPkg/PlatformPei/MemDetect.c b/OvmfPkg/PlatformPei/MemDetect.c
index 1bcb5a08bc..8ecc8257f9 100644
--- a/OvmfPkg/PlatformPei/MemDetect.c
+++ b/OvmfPkg/PlatformPei/MemDetect.c
@@ -17,6 +17,7 @@ Module Name:
 #include <IndustryStandard/I440FxPiix4.h>
 #include <IndustryStandard/Q35MchIch9.h>
 #include <IndustryStandard/CloudHv.h>
+#include <IndustryStandard/Xen/arch-x86/hvm/start_info.h>
 #include <PiPei.h>
 #include <Register/Intel/SmramSaveStateMap.h>
 
@@ -315,6 +316,73 @@ ScanOrAdd64BitE820Ram (
   return EFI_SUCCESS;
 }
 
+/**
+  Returns PVH memmap
+
+  @param Entries      Pointer to PVH memmap
+  @param Count        Number of entries
+
+  @return EFI_STATUS
+**/
+EFI_STATUS
+GetPvhMemmapEntries (
+  struct hvm_memmap_table_entry  **Entries,
+  UINT32                         *Count
+  )
+{
+  UINT32                 *PVHResetVectorData;
+  struct hvm_start_info  *pvh_start_info;
+
+  PVHResetVectorData = (VOID *)(UINTN)PcdGet32 (PcdXenPvhStartOfDayStructPtr);
+  if (PVHResetVectorData == 0) {
+    return EFI_NOT_FOUND;
+  }
+
+  pvh_start_info = (struct hvm_start_info *)(UINTN)PVHResetVectorData[0];
+
+  *Entries = (struct hvm_memmap_table_entry *)(UINTN)pvh_start_info->memmap_paddr;
+  *Count   = pvh_start_info->memmap_entries;
+
+  return EFI_SUCCESS;
+}
+
+STATIC
+UINT64
+GetHighestSystemMemoryAddressFromPvhMemmap (
+  BOOLEAN  Below4gb
+  )
+{
+  struct hvm_memmap_table_entry  *Memmap;
+  UINT32                         MemmapEntriesCount;
+  struct hvm_memmap_table_entry  *Entry;
+  EFI_STATUS                     Status;
+  UINT32                         Loop;
+  UINT64                         HighestAddress;
+  UINT64                         EntryEnd;
+
+  HighestAddress = 0;
+
+  Status = GetPvhMemmapEntries (&Memmap, &MemmapEntriesCount);
+  ASSERT_EFI_ERROR (Status);
+
+  for (Loop = 0; Loop < MemmapEntriesCount; Loop++) {
+    Entry    = Memmap + Loop;
+    EntryEnd = Entry->addr + Entry->size;
+
+    if ((Entry->type == XEN_HVM_MEMMAP_TYPE_RAM) &&
+        (EntryEnd > HighestAddress))
+    {
+      if (Below4gb && (EntryEnd <= BASE_4GB)) {
+        HighestAddress = EntryEnd;
+      } else if (!Below4gb && (EntryEnd >= BASE_4GB)) {
+        HighestAddress = EntryEnd;
+      }
+    }
+  }
+
+  return HighestAddress;
+}
+
 UINT32
 GetSystemMemorySizeBelow4gb (
   VOID
@@ -325,6 +393,11 @@ GetSystemMemorySizeBelow4gb (
   UINT8       Cmos0x34;
   UINT8       Cmos0x35;
 
+  if (mHostBridgeDevId == CLOUDHV_DEVICE_ID) {
+    // Get the information from PVH memmap
+    return (UINT32)GetHighestSystemMemoryAddressFromPvhMemmap (TRUE);
+  }
+
   Status = ScanOrAdd64BitE820Ram (FALSE, &LowerMemorySize, NULL);
   if ((Status == EFI_SUCCESS) && (LowerMemorySize > 0)) {
     return (UINT32)LowerMemorySize;
diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf b/OvmfPkg/PlatformPei/PlatformPei.inf
index 8ef404168c..212aa7b047 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -91,6 +91,8 @@
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
   gUefiOvmfPkgTokenSpaceGuid.PcdQ35SmramAtDefaultSmbase
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtr
+  gUefiOvmfPkgTokenSpaceGuid.PcdXenPvhStartOfDayStructPtrSize
   gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize
   gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
-- 
2.32.0

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [edk2-devel] [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary

[Gerd Hoffmann]

On Tue, Feb 22, 2022 at 04:53:04PM +0100, Boeuf, Sebastien wrote:
> From: Sebastien Boeuf <sebastien.boeuf@intel.com>
> 
> Following the model from the Xen target, CloudHv is generated as a PVH
> ELF binary to take advantage of the PVH specification.

> --- /dev/null
> +++ b/OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c

Why create a new copy of this?  What are the differences to the Xen
version?  I guess they are small so we can maybe have a common
ElfPvhHeaderGenerator.c with command line switches?

> -  OvmfPkg/ResetVector/ResetVector.inf
> +  OvmfPkg/XenResetVector/XenResetVector.inf

Why this is needed?

> +DATA = {
> +  #
> +  # This hex array have been generated by OvmfPkg/OvmfXenElfHeaderGenerator.c
> +  # and copied manually.

How about having the generator write a .fdf.inc file which you can just
include directly without manual copying?

take care,
  Gerd

Re: [edk2-devel] [PATCH 2/3] OvmfPkg: CloudHv: Retrieve RSDP address from PVH

[Gerd Hoffmann]

  Hi,

> +  PVHResetVectorData = (VOID *)(UINTN)PcdGet32 (PcdXenPvhStartOfDayStructPtr);
> +  pvh_start_info       = (struct hvm_start_info *)(UINTN)PVHResetVectorData[0];

Ah, I see, here is the xen reset vector dependency.

I'm wondering whenever there are plans for cloudhv to also support sev
and/or tdx some day.  If so, then it probably isn't a good idea to
switch to the xen reset vector.  There is the work area used for by
confidential computing code, I think it would be an option to store a
pointer to the pvh_start_info there.

take care,
  Gerd

Re: [edk2-devel] [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary

[Boeuf, Sebastien]

On Wed, 2022-02-23 at 12:22 +0100, Gerd Hoffmann wrote:
> On Tue, Feb 22, 2022 at 04:53:04PM +0100, Boeuf, Sebastien wrote:
> > From: Sebastien Boeuf <sebastien.boeuf@intel.com>
> > 
> > Following the model from the Xen target, CloudHv is generated as a
> > PVH
> > ELF binary to take advantage of the PVH specification.
> 
> > --- /dev/null
> > +++ b/OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c
> 
> Why create a new copy of this?  What are the differences to the Xen
> version?  I guess they are small so we can maybe have a common
> ElfPvhHeaderGenerator.c with command line switches?

That's right, I can work on updating the generator to take some
parameters so that I won't need the duplication of the file.

> 
> > -  OvmfPkg/ResetVector/ResetVector.inf
> > +  OvmfPkg/XenResetVector/XenResetVector.inf
> 
> Why this is needed?

It stores the "Start of day" structure pointer, which is then used by
some follow up patches to access hvm_start_info structure (containing
the PVH boot information).

> 
> > +DATA = {
> > +  #
> > +  # This hex array have been generated by
> > OvmfPkg/OvmfXenElfHeaderGenerator.c
> > +  # and copied manually.
> 
> How about having the generator write a .fdf.inc file which you can
> just
> include directly without manual copying?

I understand the idea, but do you have any pointer to some existing
code in the repo already doing such thing?

Thanks,
Sebastien

> 
> take care,
>   Gerd
> 

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [edk2-devel] [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary

[Boeuf, Sebastien]

On Wed, 2022-02-23 at 13:35 +0100, Sebastien Boeuf wrote:
> On Wed, 2022-02-23 at 12:22 +0100, Gerd Hoffmann wrote:
> > On Tue, Feb 22, 2022 at 04:53:04PM +0100, Boeuf, Sebastien wrote:
> > > From: Sebastien Boeuf <sebastien.boeuf@intel.com>
> > > 
> > > Following the model from the Xen target, CloudHv is generated as
> > > a
> > > PVH
> > > ELF binary to take advantage of the PVH specification.
> > 
> > > --- /dev/null
> > > +++ b/OvmfPkg/CloudHv/CloudHvElfHeaderGenerator.c
> > 
> > Why create a new copy of this?  What are the differences to the Xen
> > version?  I guess they are small so we can maybe have a common
> > ElfPvhHeaderGenerator.c with command line switches?
> 
> That's right, I can work on updating the generator to take some
> parameters so that I won't need the duplication of the file.

This has been fixed part of v2 patchset.

> 
> > 
> > > -  OvmfPkg/ResetVector/ResetVector.inf
> > > +  OvmfPkg/XenResetVector/XenResetVector.inf
> > 
> > Why this is needed?
> 
> It stores the "Start of day" structure pointer, which is then used by
> some follow up patches to access hvm_start_info structure (containing
> the PVH boot information).
> 
> > 
> > > +DATA = {
> > > +  #
> > > +  # This hex array have been generated by
> > > OvmfPkg/OvmfXenElfHeaderGenerator.c
> > > +  # and copied manually.
> > 
> > How about having the generator write a .fdf.inc file which you can
> > just
> > include directly without manual copying?
> 
> I understand the idea, but do you have any pointer to some existing
> code in the repo already doing such thing?
> 
> Thanks,
> Sebastien
> 
> > 
> > take care,
> >   Gerd
> > 
> 

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [edk2-devel] [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary

[Gerd Hoffmann]

> > > +DATA = {
> > > +  #
> > > +  # This hex array have been generated by
> > > OvmfPkg/OvmfXenElfHeaderGenerator.c
> > > +  # and copied manually.
> > 
> > How about having the generator write a .fdf.inc file which you can
> > just
> > include directly without manual copying?
> 
> I understand the idea, but do you have any pointer to some existing
> code in the repo already doing such thing?

I'd suggest to just commit the generated include file to git instead of
hooking the generator call into the build system, i.e. updating it would
still be a manual process, but easier and less error-prone because the
manual copying goes away.

take care,
  Gerd

Re: [edk2-devel] [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary

[Boeuf, Sebastien]

On Thu, 2022-02-24 at 07:27 +0100, Gerd Hoffmann wrote:
> > > > +DATA = {
> > > > +  #
> > > > +  # This hex array have been generated by
> > > > OvmfPkg/OvmfXenElfHeaderGenerator.c
> > > > +  # and copied manually.
> > > 
> > > How about having the generator write a .fdf.inc file which you
> > > can
> > > just
> > > include directly without manual copying?
> > 
> > I understand the idea, but do you have any pointer to some existing
> > code in the repo already doing such thing?
> 
> I'd suggest to just commit the generated include file to git instead
> of
> hooking the generator call into the build system, i.e. updating it
> would
> still be a manual process, but easier and less error-prone because
> the
> manual copying goes away.

I took care of that in the v3.
> 
> take care,
>   Gerd
> 
> 
> 
> 
> 
> 

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [edk2-devel] [PATCH 2/3] OvmfPkg: CloudHv: Retrieve RSDP address from PVH

[Boeuf, Sebastien]

On Wed, 2022-02-23 at 12:31 +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > +  PVHResetVectorData = (VOID *)(UINTN)PcdGet32
> > (PcdXenPvhStartOfDayStructPtr);
> > +  pvh_start_info       = (struct hvm_start_info
> > *)(UINTN)PVHResetVectorData[0];
> 
> Ah, I see, here is the xen reset vector dependency.
> 
> I'm wondering whenever there are plans for cloudhv to also support
> sev
> and/or tdx some day.  If so, then it probably isn't a good idea to
> switch to the xen reset vector.  

Well Cloud Hypervisor aims at supporting TDX, but based on a separate
firmware. We're not trying to support both TDX and non-TDX use cases
with the same binary, which simplifies the problem here.

> There is the work area used for by
> confidential computing code, I think it would be an option to store a
> pointer to the pvh_start_info there.

Sorry I'm not aware of the confidential computing code. Can you point
me to it?

> 
> take care,
>   Gerd
> 
> 
> 
> 
> 
> 

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [edk2-devel] [PATCH 2/3] OvmfPkg: CloudHv: Retrieve RSDP address from PVH

[Gerd Hoffmann]

  Hi,

> > I'm wondering whenever there are plans for cloudhv to also support
> > sev
> > and/or tdx some day.  If so, then it probably isn't a good idea to
> > switch to the xen reset vector.  
> 
> Well Cloud Hypervisor aims at supporting TDX, but based on a separate
> firmware. We're not trying to support both TDX and non-TDX use cases
> with the same binary, which simplifies the problem here.

If tdx will be another binary anyway then it doesn't matter much I guess.

> > There is the work area used for by
> > confidential computing code, I think it would be an option to store a
> > pointer to the pvh_start_info there.
> 
> Sorry I'm not aware of the confidential computing code. Can you point
> me to it?

OvmfPkg/Include/WorkArea.h

git grep WORK_AREA -- OvmfPkg/ResetVector

take care,
  Gerd