* [PATCH v2 0/5] CloudHv: Rely on PVH boot specification
@ 2022-02-23 16:51 Boeuf, Sebastien
2022-02-23 16:51 ` [PATCH v2 1/5] OvmfPkg: Make the Xen ELF header generator more flexible Boeuf, Sebastien
` (4 more replies)
0 siblings, 5 replies; 11+ messages in thread
From: Boeuf, Sebastien @ 2022-02-23 16:51 UTC (permalink / raw)
To: devel; +Cc: jiewen.yao, jordan.l.justen, kraxel, sebastien.boeuf
From: Sebastien Boeuf <sebastien.boeuf@intel.com>
Cloud Hypervisor aims at emulating the minimal amount of legacy devices
and this is why the PVH boot specification is supported. The point is to
be able to share some information with the guest without the need for
emulating devices that would be present on real hardware.
Since Cloud Hypervisor supports loading a PVH ELF binary, the CloudHv
target is updated to be generated as such. Relying on the PVH boot
specification, we don't need to hardcode the location of the ACPI tables
anymore since we can retrieve the RSDP address from the hvm_start_info
structure. Same thing for the RAM below 4G, we can find this information
through the PVH memmap entries rather than relying on the emulated CMOS.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Sebastien Boeuf (5):
OvmfPkg: Make the Xen ELF header generator more flexible
OvmfPkg: Generate CloudHv as a PVH ELF binary
OvmfPkg: CloudHv: Retrieve RSDP address from PVH
OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS
OvmfPkg: CloudHv: Add README
OvmfPkg/AcpiPlatformDxe/AcpiPlatformDxe.inf | 2 +
OvmfPkg/AcpiPlatformDxe/CloudHvAcpi.c | 39 ++++++---
OvmfPkg/CloudHv/CloudHvX64.dsc | 2 +-
OvmfPkg/CloudHv/CloudHvX64.fdf | 97 ++++++++++++++++++++-
OvmfPkg/CloudHv/README | 66 ++++++++++++++
OvmfPkg/Include/IndustryStandard/CloudHv.h | 5 --
OvmfPkg/OvmfXenElfHeaderGenerator.c | 63 ++++++++++---
OvmfPkg/PlatformPei/MemDetect.c | 73 ++++++++++++++++
OvmfPkg/PlatformPei/PlatformPei.inf | 2 +
9 files changed, 318 insertions(+), 31 deletions(-)
create mode 100644 OvmfPkg/CloudHv/README
--
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 [flat|nested] 11+ messages in thread* [PATCH v2 1/5] OvmfPkg: Make the Xen ELF header generator more flexible 2022-02-23 16:51 [PATCH v2 0/5] CloudHv: Rely on PVH boot specification Boeuf, Sebastien @ 2022-02-23 16:51 ` Boeuf, Sebastien 2022-02-24 8:07 ` Gerd Hoffmann 2022-02-23 16:51 ` [PATCH v2 2/5] OvmfPkg: Generate CloudHv as a PVH ELF binary Boeuf, Sebastien ` (3 subsequent siblings) 4 siblings, 1 reply; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-23 16:51 UTC (permalink / raw) To: devel; +Cc: jiewen.yao, jordan.l.justen, kraxel, sebastien.boeuf From: Sebastien Boeuf <sebastien.boeuf@intel.com> Adding some flexibility to the program so that other targets can use it if needed. An optional size parameter is added so that we can provide the expected blob size of the generated binary. A global define is added so that we can choose at build time if we want to use 32-bit or 64-bit bases structures. The default behavior isn't modified. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com> --- OvmfPkg/OvmfXenElfHeaderGenerator.c | 63 ++++++++++++++++++++++++----- 1 file changed, 52 insertions(+), 11 deletions(-) diff --git a/OvmfPkg/OvmfXenElfHeaderGenerator.c b/OvmfPkg/OvmfXenElfHeaderGenerator.c index 489060cdad..a054c77cda 100644 --- a/OvmfPkg/OvmfXenElfHeaderGenerator.c +++ b/OvmfPkg/OvmfXenElfHeaderGenerator.c @@ -12,6 +12,7 @@ #include "elf.h" #include "stdio.h" #include "stddef.h" +#include "stdlib.h" void print_hdr ( @@ -38,7 +39,8 @@ typedef struct { int main ( - void + int argc, + char *argv[] ) { /* FW_SIZE */ @@ -47,23 +49,46 @@ main ( 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; + size_t offset_into_file = 0; + char *endptr, *str; + long param; + + /* Parse the size parameter */ + if (argc > 1) { + str = argv[1]; + param = strtol (str, &endptr, 10); + if (endptr != str) { + ovmf_blob_size = (size_t)param; + } + } /* ELF file header */ + #ifdef PVH64 + Elf64_Ehdr hdr = { + #else Elf32_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), + #endif + .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), + #ifdef PVH64 + .e_phentsize = sizeof (Elf64_Phdr), + #else .e_phentsize = sizeof (Elf32_Phdr), + #endif }; offset_into_file += sizeof (hdr); - hdr.e_ident[EI_CLASS] = ELFCLASS32; + #ifdef PVH64 + hdr.e_ident[EI_CLASS] = ELFCLASS64; + #else + hdr.e_ident[EI_CLASS] = ELFCLASS32; + #endif hdr.e_ident[EI_DATA] = ELFDATA2LSB; hdr.e_ident[EI_VERSION] = EV_CURRENT; hdr.e_ident[EI_OSABI] = ELFOSABI_LINUX; @@ -71,14 +96,22 @@ main ( hdr.e_phoff = sizeof (hdr); /* program header */ + #ifdef PVH64 + Elf64_Phdr phdr_load = { + #else Elf32_Phdr phdr_load = { + #endif .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, + #ifdef PVH64 + .p_align = 4, + #else .p_align = 0, + #endif }; phdr_load.p_vaddr = phdr_load.p_paddr; @@ -98,12 +131,20 @@ main ( sizeof (xen_elfnote_phys32_entry) - offsetof (xen_elfnote_phys32_entry, desc), }; - Elf32_Phdr phdr_note = { + #ifdef PVH64 + Elf64_Phdr phdr_note = { + #else + Elf32_Phdr phdr_note = { + #endif .p_type = PT_NOTE, .p_filesz = sizeof (xen_elf_note), .p_memsz = sizeof (xen_elf_note), .p_flags = PF_R, + #ifdef PVH64 + .p_align = 4, + #else .p_align = 0, + #endif }; hdr.e_phnum += 1; -- 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: [PATCH v2 1/5] OvmfPkg: Make the Xen ELF header generator more flexible 2022-02-23 16:51 ` [PATCH v2 1/5] OvmfPkg: Make the Xen ELF header generator more flexible Boeuf, Sebastien @ 2022-02-24 8:07 ` Gerd Hoffmann 0 siblings, 0 replies; 11+ messages in thread From: Gerd Hoffmann @ 2022-02-24 8:07 UTC (permalink / raw) To: sebastien.boeuf; +Cc: devel, jiewen.yao, jordan.l.justen On Wed, Feb 23, 2022 at 05:51:26PM +0100, sebastien.boeuf@intel.com wrote: > From: Sebastien Boeuf <sebastien.boeuf@intel.com> > > Adding some flexibility to the program so that other targets can use it > if needed. > > An optional size parameter is added so that we can provide the expected > blob size of the generated binary. > > A global define is added so that we can choose at build time if we want > to use 32-bit or 64-bit bases structures. > > The default behavior isn't modified. Acked-by: Gerd Hoffmann <kraxel@redhat.com> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v2 2/5] OvmfPkg: Generate CloudHv as a PVH ELF binary 2022-02-23 16:51 [PATCH v2 0/5] CloudHv: Rely on PVH boot specification Boeuf, Sebastien 2022-02-23 16:51 ` [PATCH v2 1/5] OvmfPkg: Make the Xen ELF header generator more flexible Boeuf, Sebastien @ 2022-02-23 16:51 ` Boeuf, Sebastien 2022-02-24 8:16 ` Gerd Hoffmann 2022-02-23 16:51 ` [PATCH v2 3/5] OvmfPkg: CloudHv: Retrieve RSDP address from PVH Boeuf, Sebastien ` (2 subsequent siblings) 4 siblings, 1 reply; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-23 16:51 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/CloudHvX64.dsc | 2 +- OvmfPkg/CloudHv/CloudHvX64.fdf | 94 +++++++++++++++++++++++++++++++++- 2 files changed, 93 insertions(+), 3 deletions(-) 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..8eeaaaabcf 100644 --- a/OvmfPkg/CloudHv/CloudHvX64.fdf +++ b/OvmfPkg/CloudHv/CloudHvX64.fdf @@ -24,7 +24,97 @@ 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. + # Built with "gcc -D PVH64 -o elf_gen OvmfPkg/OvmfXenElfHeaderGenerator.c" + # and run with "./elf_gen 4194304". + # + # 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 +232,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: [PATCH v2 2/5] OvmfPkg: Generate CloudHv as a PVH ELF binary 2022-02-23 16:51 ` [PATCH v2 2/5] OvmfPkg: Generate CloudHv as a PVH ELF binary Boeuf, Sebastien @ 2022-02-24 8:16 ` Gerd Hoffmann 2022-02-24 15:12 ` [edk2-devel] " Boeuf, Sebastien 0 siblings, 1 reply; 11+ messages in thread From: Gerd Hoffmann @ 2022-02-24 8:16 UTC (permalink / raw) To: sebastien.boeuf; +Cc: devel, jiewen.yao, jordan.l.justen Hi, > -!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 Hmm, VarStore.fdf.inc reduces duplication, and now you revert this. Maybe add this to VarStore.fdf.inc instead, and add a PVH_HEADER_ENABLE option to turn it on and off? Also: With this in place the start of the vars firmware volume moves because it's prefixed by the elf header. Does that work without code changes? take care, Gerd ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [edk2-devel] [PATCH v2 2/5] OvmfPkg: Generate CloudHv as a PVH ELF binary 2022-02-24 8:16 ` Gerd Hoffmann @ 2022-02-24 15:12 ` Boeuf, Sebastien 2022-02-25 9:29 ` Gerd Hoffmann 0 siblings, 1 reply; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-24 15:12 UTC (permalink / raw) To: kraxel@redhat.com, devel@edk2.groups.io; +Cc: Yao, Jiewen, Justen, Jordan L On Thu, 2022-02-24 at 09:16 +0100, Gerd Hoffmann wrote: > Hi, > > > -!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 > > Hmm, VarStore.fdf.inc reduces duplication, and now you revert this. > Maybe add this to VarStore.fdf.inc instead, and add a > PVH_HEADER_ENABLE > option to turn it on and off? It's quite hard to use VarStore.fdf.inc since I would need to replace only the first DATA section. And I can't include something specific like OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc inside VarStore.fdf.inc. Should I create something like OvmfPkg/CloudHv/CloudHvVarStore.fdf.inc so that it makes sense to include OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc based on a PVH_HEADER_ENABLE variable? > > Also: With this in place the start of the vars firmware volume moves > because it's prefixed by the elf header. Does that work without code > changes? TBH, I'm not sure. I've been testing CLOUDHV.fd and it works fine. > > 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 v2 2/5] OvmfPkg: Generate CloudHv as a PVH ELF binary 2022-02-24 15:12 ` [edk2-devel] " Boeuf, Sebastien @ 2022-02-25 9:29 ` Gerd Hoffmann 2022-02-25 10:49 ` Boeuf, Sebastien 0 siblings, 1 reply; 11+ messages in thread From: Gerd Hoffmann @ 2022-02-25 9:29 UTC (permalink / raw) To: Boeuf, Sebastien; +Cc: devel@edk2.groups.io, Yao, Jiewen, Justen, Jordan L Hi, > > Hmm, VarStore.fdf.inc reduces duplication, and now you revert this. > > Maybe add this to VarStore.fdf.inc instead, and add a > > PVH_HEADER_ENABLE > > option to turn it on and off? > > It's quite hard to use VarStore.fdf.inc since I would need to replace > only the first DATA section. And I can't include something specific > like OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc inside VarStore.fdf.inc. > Should I create something like OvmfPkg/CloudHv/CloudHvVarStore.fdf.inc > so that it makes sense to include > OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc based on a PVH_HEADER_ENABLE > variable? Yes, that was the idea, only include the file in case PVH_HEADER_ENABLE=TRUE. Maybe name it "PVH_HEADER_CLOUDHW" so the xen guys can add PVH_HEADER_XEN variable for the simliar but not identical xen case. take care, Gerd ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [edk2-devel] [PATCH v2 2/5] OvmfPkg: Generate CloudHv as a PVH ELF binary 2022-02-25 9:29 ` Gerd Hoffmann @ 2022-02-25 10:49 ` Boeuf, Sebastien 0 siblings, 0 replies; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-25 10:49 UTC (permalink / raw) To: kraxel@redhat.com; +Cc: Yao, Jiewen, Justen, Jordan L, devel@edk2.groups.io On Fri, 2022-02-25 at 10:29 +0100, kraxel@redhat.com wrote: > Hi, > > > > Hmm, VarStore.fdf.inc reduces duplication, and now you revert > > > this. > > > Maybe add this to VarStore.fdf.inc instead, and add a > > > PVH_HEADER_ENABLE > > > option to turn it on and off? > > > > It's quite hard to use VarStore.fdf.inc since I would need to > > replace > > only the first DATA section. And I can't include something specific > > like OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc inside > > VarStore.fdf.inc. > > Should I create something like > > OvmfPkg/CloudHv/CloudHvVarStore.fdf.inc > > so that it makes sense to include > > OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc based on a > > PVH_HEADER_ENABLE > > variable? > > Yes, that was the idea, only include the file in case > PVH_HEADER_ENABLE=TRUE. Maybe name it "PVH_HEADER_CLOUDHW" so the > xen > guys can add PVH_HEADER_XEN variable for the simliar but not > identical > xen case. I took care of it on the 4th patch through the v4 I've just sent. Let me know if that's what you were expecting. Thanks, Seb > > 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 v2 3/5] OvmfPkg: CloudHv: Retrieve RSDP address from PVH 2022-02-23 16:51 [PATCH v2 0/5] CloudHv: Rely on PVH boot specification Boeuf, Sebastien 2022-02-23 16:51 ` [PATCH v2 1/5] OvmfPkg: Make the Xen ELF header generator more flexible Boeuf, Sebastien 2022-02-23 16:51 ` [PATCH v2 2/5] OvmfPkg: Generate CloudHv as a PVH ELF binary Boeuf, Sebastien @ 2022-02-23 16:51 ` Boeuf, Sebastien 2022-02-23 16:51 ` [PATCH v2 4/5] OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS Boeuf, Sebastien 2022-02-23 16:51 ` [PATCH v2 5/5] OvmfPkg: CloudHv: Add README Boeuf, Sebastien 4 siblings, 0 replies; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-23 16:51 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 8eeaaaabcf..9db03380a1 100644 --- a/OvmfPkg/CloudHv/CloudHvX64.fdf +++ b/OvmfPkg/CloudHv/CloudHvX64.fdf @@ -184,6 +184,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
* [PATCH v2 4/5] OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS 2022-02-23 16:51 [PATCH v2 0/5] CloudHv: Rely on PVH boot specification Boeuf, Sebastien ` (2 preceding siblings ...) 2022-02-23 16:51 ` [PATCH v2 3/5] OvmfPkg: CloudHv: Retrieve RSDP address from PVH Boeuf, Sebastien @ 2022-02-23 16:51 ` Boeuf, Sebastien 2022-02-23 16:51 ` [PATCH v2 5/5] OvmfPkg: CloudHv: Add README Boeuf, Sebastien 4 siblings, 0 replies; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-23 16:51 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
* [PATCH v2 5/5] OvmfPkg: CloudHv: Add README 2022-02-23 16:51 [PATCH v2 0/5] CloudHv: Rely on PVH boot specification Boeuf, Sebastien ` (3 preceding siblings ...) 2022-02-23 16:51 ` [PATCH v2 4/5] OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS Boeuf, Sebastien @ 2022-02-23 16:51 ` Boeuf, Sebastien 4 siblings, 0 replies; 11+ messages in thread From: Boeuf, Sebastien @ 2022-02-23 16:51 UTC (permalink / raw) To: devel; +Cc: jiewen.yao, jordan.l.justen, kraxel, sebastien.boeuf From: Sebastien Boeuf <sebastien.boeuf@intel.com> Add some documentation to the CloudHv target in order to clarify how to use it and what to expect from it. Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com> --- OvmfPkg/CloudHv/README | 66 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 OvmfPkg/CloudHv/README diff --git a/OvmfPkg/CloudHv/README b/OvmfPkg/CloudHv/README new file mode 100644 index 0000000000..ffd4f19c50 --- /dev/null +++ b/OvmfPkg/CloudHv/README @@ -0,0 +1,66 @@ + +CloudHv is a port of OVMF for the Cloud Hypervisor project. + +The Cloud Hypervisor project +---------------------------- + +Cloud Hypervisor is a Virtual Machine Monitor that runs on top of KVM. The +project focuses on exclusively running modern, cloud workloads, on top of a +limited set of hardware architectures and platforms. Cloud workloads refers to +those that are usually run by customers inside a cloud provider. This means +modern operating systems with most I/O handled by paravirtualised devices +(i.e. virtio), no requirement for legacy devices, and 64-bit CPUs. + +https://github.com/cloud-hypervisor/cloud-hypervisor + +Design +------ + +Based on Cloud Hypervisor's motto to reduce the emulation as much as possible, +the project logically decided to support the PVH boot specification as the only +way of booting virtual machines. That includes both direct kernel boot and OVMF +firmware which must be generated as PVH ELF binaries. +PVH allows information like location of ACPI tables and location of guest RAM +ranges to be shared without the need of an extra emulated device like a CMOS. + +Features +-------- + +* Serial console +* EFI shell +* virtio-pci + +Build +----- + +The way to build the CloudHv target is as follows: + +OvmfPkg/build.sh -p OvmfPkg/CloudHv/CloudHvX64.dsc -a X64 -b DEBUG + +Usage +----- + +Assuming Cloud Hypervisor is already built, one can start a virtual machine as +follows: + +./cloud-hypervisor \ + --cpus boot=1 \ + --memory size=1G \ + --kernel Build/CloudHvX64/DEBUG_GCC5/FV/CLOUDHV.fd \ + --disk path=/path/to/disk.raw + +Releases +-------- + +In edk2-stable202202, CloudHv is generated as data-only binary. +Starting with edk2-stable202205, CloudHv is generated as a PVH ELF binary to +reduce the amount of emulation needed from Cloud Hypervisor. +For TDX, things are handled differently and PVH is not used, which is why the +firmware is always generated as a data-only binary. + ++-------------------+----------------+-------------+ +| CloudHv | non-TDX | TDX | ++-------------------+----------------+-------------+ +| edk2-stable202202 | Data binary | Data binary | +| edk2-stable202205 | PVH ELF binary | Data binary | ++-------------------+----------------+-------------+ \ No newline at end of file -- 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 10:49 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-02-23 16:51 [PATCH v2 0/5] CloudHv: Rely on PVH boot specification Boeuf, Sebastien 2022-02-23 16:51 ` [PATCH v2 1/5] OvmfPkg: Make the Xen ELF header generator more flexible Boeuf, Sebastien 2022-02-24 8:07 ` Gerd Hoffmann 2022-02-23 16:51 ` [PATCH v2 2/5] OvmfPkg: Generate CloudHv as a PVH ELF binary Boeuf, Sebastien 2022-02-24 8:16 ` Gerd Hoffmann 2022-02-24 15:12 ` [edk2-devel] " Boeuf, Sebastien 2022-02-25 9:29 ` Gerd Hoffmann 2022-02-25 10:49 ` Boeuf, Sebastien 2022-02-23 16:51 ` [PATCH v2 3/5] OvmfPkg: CloudHv: Retrieve RSDP address from PVH Boeuf, Sebastien 2022-02-23 16:51 ` [PATCH v2 4/5] OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS Boeuf, Sebastien 2022-02-23 16:51 ` [PATCH v2 5/5] OvmfPkg: CloudHv: Add README Boeuf, Sebastien
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox