public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: sebastien.boeuf@intel.com
Cc: devel@edk2.groups.io, jiewen.yao@intel.com, jordan.l.justen@intel.com
Subject: Re: [PATCH v4 4/7] OvmfPkg: Generate CloudHv as a PVH ELF binary
Date: Fri, 25 Feb 2022 14:00:53 +0100	[thread overview]
Message-ID: <20220225130053.oizxc47lhvyr5cim@sirius.home.kraxel.org> (raw)
In-Reply-To: <b2e66b0e64bf6f0bed4d4b92df5a433e348e4c44.1645785801.git.sebastien.boeuf@intel.com>

> +++ b/OvmfPkg/CloudHv/CloudHvX64.fdf
> @@ -14,8 +14,8 @@
>  !include OvmfPkg/OvmfPkgDefines.fdf.inc
>  
>  #
> -# Build the variable store and the firmware code as one unified flash device
> -# image.
> +# This will allow the flash device image to be recognize as an ELF, with first
> +# an ELF headers, then the firmware code.
>  #
>  [FD.CLOUDHV]
>  BaseAddress   = $(FW_BASE_ADDRESS)
> @@ -24,7 +24,9 @@ ErasePolarity = 1
>  BlockSize     = $(BLOCK_SIZE)
>  NumBlocks     = $(FW_BLOCKS)
>  
> +DEFINE PVH_HEADER_CLOUDHV = TRUE

I'd place the define in CloudHvX64.dsc, in the [Defines] section, where
all the other DEFINE statements are too.

>  !include OvmfPkg/VarStore.fdf.inc
> +DEFINE PVH_HEADER_CLOUDHV = FALSE

No need to flip that back to FALSE.

> +!if $(PVH_HEADER_CLOUDHV) == TRUE
> +!include OvmfPkg/CloudHv/CloudHvElfHeader.fdf.inc
> +!else
>  DATA = {
>    ## This is the EFI_FIRMWARE_VOLUME_HEADER
>    # ZeroVector []
> @@ -79,6 +83,7 @@ DATA = {
>    # FORMATTED: 0x5A #HEALTHY: 0xFE #Reserved: UINT16 #Reserved1: UINT32
>    0x5A, 0xFE, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
>  }
> +!endif

Oh.  So the ELF header *replaces* the firmware volume header.
Didn't notice that before.

Hmm.  With that the varstore initialization most likely fails.
There is a fallback path though, with ovmf storing variables
elsewhere (in normal ram instead of firmware flash I think).
Persistent variables don't work in that case.

When the persistent varstore doesn't work anyway (and you are
ok with that) you probably can drop the space reserved for it
from the firmware image and use just a single page for the pvh
elf header (and sharing VarStore.fdf doesn't make sense then).

take care,
  Gerd


  reply	other threads:[~2022-02-25 13:01 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-25 10:45 [PATCH v4 0/7] CloudHv: Rely on PVH boot specification Boeuf, Sebastien
2022-02-25 10:45 ` [PATCH v4 1/7] OvmfPkg: Make the Xen ELF header generator more flexible Boeuf, Sebastien
2022-02-25 10:45 ` [PATCH v4 2/7] OvmfPkg: Xen: Use a new fdf include for the PVH ELF header Boeuf, Sebastien
2022-02-25 10:45 ` [PATCH v4 3/7] OvmfPkg: Xen: Generate fdf include file from ELF header generator Boeuf, Sebastien
2022-02-25 10:45 ` [PATCH v4 4/7] OvmfPkg: Generate CloudHv as a PVH ELF binary Boeuf, Sebastien
2022-02-25 13:00   ` Gerd Hoffmann [this message]
2022-02-25 14:00     ` [edk2-devel] " Boeuf, Sebastien
2022-02-28  7:08       ` Gerd Hoffmann
2022-02-28  8:15         ` Boeuf, Sebastien
     [not found]         ` <16D7E5267B34FC87.32375@groups.io>
2022-02-28 15:12           ` Boeuf, Sebastien
2022-03-01  7:16             ` Gerd Hoffmann
2022-03-01  8:53               ` Boeuf, Sebastien
2022-03-01 11:28                 ` Gerd Hoffmann
2022-03-01 13:30                   ` Boeuf, Sebastien
     [not found]               ` <16D835C7D9FE3DA1.466@groups.io>
2022-03-01  9:17                 ` Boeuf, Sebastien
2022-02-25 10:45 ` [PATCH v4 5/7] OvmfPkg: CloudHv: Retrieve RSDP address from PVH Boeuf, Sebastien
2022-02-25 10:45 ` [PATCH v4 6/7] OvmfPkg: CloudHv: Rely on PVH memmap instead of CMOS Boeuf, Sebastien
2022-02-25 10:45 ` [PATCH v4 7/7] OvmfPkg: CloudHv: Add README Boeuf, Sebastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220225130053.oizxc47lhvyr5cim@sirius.home.kraxel.org \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox