public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Boeuf, Sebastien" <sebastien.boeuf@intel.com>
To: "kraxel@redhat.com" <kraxel@redhat.com>,
	"devel@edk2.groups.io" <devel@edk2.groups.io>
Cc: "Yao, Jiewen" <jiewen.yao@intel.com>,
	"Justen, Jordan L" <jordan.l.justen@intel.com>
Subject: Re: [edk2-devel] [PATCH v4 4/7] OvmfPkg: Generate CloudHv as a PVH ELF binary
Date: Mon, 28 Feb 2022 08:15:36 +0000	[thread overview]
Message-ID: <6ed49463c9a7a2eea1a8d10069ff7e4109a45c8b.camel@intel.com> (raw)
In-Reply-To: <20220228070808.ao753pdtfupp3qs4@sirius.home.kraxel.org>

On Mon, 2022-02-28 at 08:08 +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > > 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).
> > 
> > Sorry it's not entirely clear to me what should be done here.
> > Should I
> > remove the VARS section since we're not using it anyway?
> > I'm lacking some knowledge here to understand what this is used
> > for,
> > and how I actually broke it. I mean with the define and the
> > include, I
> > ended up modifying exclusively the [FD.CLOUDHV] which is exactly
> > what
> > was done for Xen. Do you think the Xen VARS section is broken as
> > well?
> 
> Probably.  Not sure how xen uses the generated firmware images
> though.
> 
> OVMF has three images.  The OVMF_VARS.fd is the variable store.
> OVMF_CODE.fd is the firmware code.  Both combined is OVMF.fd.  The
> split
> into VARS and CODE exists to simplify firmware updates:  On the host
> machine you'll have a per-guest VARS file with the persistent uefi
> variables, and the shared CODE file.  Firmware upgrades work by
> simply
> updating the shared CODE file.
> 
> The address space layout is the same in both cases
> (combined/splitted).
> The firmware takes 2M or 4M below 4G.  The upper part is covered by
> the
> CODE, the lower part is covered by VARS.  OVMF expects the varstore
> at
> a fixes address, but as mentioned can cope with the varstore not
> being
> there or not being backed by flash.

Thanks for the explanation, it helps :)

> 
> So, do you use the CODE or VARS file for cloudhv?

No we don't.

> Does cloudhv emulate flash?

No it doesn't.

> 
> 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.

  reply	other threads:[~2022-02-28  8:15 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
2022-02-25 14:00     ` [edk2-devel] " Boeuf, Sebastien
2022-02-28  7:08       ` Gerd Hoffmann
2022-02-28  8:15         ` Boeuf, Sebastien [this message]
     [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=6ed49463c9a7a2eea1a8d10069ff7e4109a45c8b.camel@intel.com \
    --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