* [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary [not found] <cover.1645542995.git.sebastien.boeuf@intel.com> @ 2022-02-22 15:53 ` Boeuf, Sebastien 2022-02-23 11:22 ` [edk2-devel] " Gerd Hoffmann 2022-02-22 15:53 ` [PATCH 2/3] OvmfPkg: CloudHv: Retrieve RSDP address from PVH Boeuf, Sebastien 2022-02-22 15:53 ` [PATCH 3/3] OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS Boeuf, Sebastien 2 siblings, 1 reply; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-22 15:53 UTC (permalink / raw) To: devel; +Cc: jiewen.yao, jordan.l.justen, kraxel, sebastien.boeuf 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. ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [edk2-devel] [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary 2022-02-22 15:53 ` [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary Boeuf, Sebastien @ 2022-02-23 11:22 ` Gerd Hoffmann 2022-02-23 12:35 ` Boeuf, Sebastien 0 siblings, 1 reply; 11+ messages in thread From: Gerd Hoffmann @ 2022-02-23 11:22 UTC (permalink / raw) To: devel, sebastien.boeuf; +Cc: jiewen.yao, jordan.l.justen 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [edk2-devel] [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary 2022-02-23 11:22 ` [edk2-devel] " Gerd Hoffmann @ 2022-02-23 12:35 ` Boeuf, Sebastien 2022-02-23 17:29 ` Boeuf, Sebastien 2022-02-24 6:27 ` Gerd Hoffmann 0 siblings, 2 replies; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-23 12:35 UTC (permalink / raw) To: kraxel@redhat.com, devel@edk2.groups.io; +Cc: Yao, Jiewen, Justen, Jordan L 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [edk2-devel] [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary 2022-02-23 12:35 ` Boeuf, Sebastien @ 2022-02-23 17:29 ` Boeuf, Sebastien 2022-02-24 6:27 ` Gerd Hoffmann 1 sibling, 0 replies; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-23 17:29 UTC (permalink / raw) To: kraxel@redhat.com, devel@edk2.groups.io; +Cc: Yao, Jiewen, Justen, Jordan L 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [edk2-devel] [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary 2022-02-23 12:35 ` Boeuf, Sebastien 2022-02-23 17:29 ` Boeuf, Sebastien @ 2022-02-24 6:27 ` Gerd Hoffmann 2022-02-24 14:35 ` Boeuf, Sebastien 1 sibling, 1 reply; 11+ messages in thread From: Gerd Hoffmann @ 2022-02-24 6:27 UTC (permalink / raw) To: Boeuf, Sebastien; +Cc: devel@edk2.groups.io, Yao, Jiewen, Justen, Jordan L > > > +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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [edk2-devel] [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary 2022-02-24 6:27 ` Gerd Hoffmann @ 2022-02-24 14:35 ` Boeuf, Sebastien 0 siblings, 0 replies; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-24 14:35 UTC (permalink / raw) To: kraxel@redhat.com, devel@edk2.groups.io; +Cc: Yao, Jiewen, Justen, Jordan L 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 2/3] OvmfPkg: CloudHv: Retrieve RSDP address from PVH [not found] <cover.1645542995.git.sebastien.boeuf@intel.com> 2022-02-22 15:53 ` [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary Boeuf, Sebastien @ 2022-02-22 15:53 ` Boeuf, Sebastien 2022-02-23 11:31 ` [edk2-devel] " Gerd Hoffmann 2022-02-22 15:53 ` [PATCH 3/3] OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS Boeuf, Sebastien 2 siblings, 1 reply; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-22 15:53 UTC (permalink / raw) To: devel; +Cc: jiewen.yao, jordan.l.justen, kraxel, sebastien.boeuf 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. ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [edk2-devel] [PATCH 2/3] OvmfPkg: CloudHv: Retrieve RSDP address from PVH 2022-02-22 15:53 ` [PATCH 2/3] OvmfPkg: CloudHv: Retrieve RSDP address from PVH Boeuf, Sebastien @ 2022-02-23 11:31 ` Gerd Hoffmann 2022-02-24 14:41 ` Boeuf, Sebastien 0 siblings, 1 reply; 11+ messages in thread From: Gerd Hoffmann @ 2022-02-23 11:31 UTC (permalink / raw) To: devel, sebastien.boeuf; +Cc: jiewen.yao, jordan.l.justen 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [edk2-devel] [PATCH 2/3] OvmfPkg: CloudHv: Retrieve RSDP address from PVH 2022-02-23 11:31 ` [edk2-devel] " Gerd Hoffmann @ 2022-02-24 14:41 ` Boeuf, Sebastien 2022-02-25 9:34 ` Gerd Hoffmann 0 siblings, 1 reply; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-24 14:41 UTC (permalink / raw) To: kraxel@redhat.com, devel@edk2.groups.io; +Cc: Yao, Jiewen, Justen, Jordan L 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [edk2-devel] [PATCH 2/3] OvmfPkg: CloudHv: Retrieve RSDP address from PVH 2022-02-24 14:41 ` Boeuf, Sebastien @ 2022-02-25 9:34 ` Gerd Hoffmann 0 siblings, 0 replies; 11+ messages in thread From: Gerd Hoffmann @ 2022-02-25 9:34 UTC (permalink / raw) To: devel, sebastien.boeuf; +Cc: Yao, Jiewen, Justen, Jordan L 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 3/3] OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS [not found] <cover.1645542995.git.sebastien.boeuf@intel.com> 2022-02-22 15:53 ` [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary Boeuf, Sebastien 2022-02-22 15:53 ` [PATCH 2/3] OvmfPkg: CloudHv: Retrieve RSDP address from PVH Boeuf, Sebastien @ 2022-02-22 15:53 ` Boeuf, Sebastien 2 siblings, 0 replies; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-22 15:53 UTC (permalink / raw) To: devel; +Cc: jiewen.yao, jordan.l.justen, kraxel, sebastien.boeuf 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. ^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-02-25 9:34 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <cover.1645542995.git.sebastien.boeuf@intel.com> 2022-02-22 15:53 ` [PATCH 1/3] OvmfPkg: Generate CloudHv as a PVH ELF binary Boeuf, Sebastien 2022-02-23 11:22 ` [edk2-devel] " Gerd Hoffmann 2022-02-23 12:35 ` Boeuf, Sebastien 2022-02-23 17:29 ` Boeuf, Sebastien 2022-02-24 6:27 ` Gerd Hoffmann 2022-02-24 14:35 ` Boeuf, Sebastien 2022-02-22 15:53 ` [PATCH 2/3] OvmfPkg: CloudHv: Retrieve RSDP address from PVH Boeuf, Sebastien 2022-02-23 11:31 ` [edk2-devel] " Gerd Hoffmann 2022-02-24 14:41 ` Boeuf, Sebastien 2022-02-25 9:34 ` Gerd Hoffmann 2022-02-22 15:53 ` [PATCH 3/3] OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS Boeuf, Sebastien
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox