From: "Ard Biesheuvel" <ardb@kernel.org>
To: Devon Bautista <dbautista@newmexicoconsortium.org>,
Gerd Hoffmann <kraxel@redhat.com>
Cc: edk2-devel-groups-io <devel@edk2.groups.io>,
Ard Biesheuvel <ardb+tianocore@kernel.org>,
Jiewen Yao <jiewen.yao@intel.com>,
Jordan Justen <jordan.l.justen@intel.com>
Subject: Re: OVMF: NV Variable Store Layout of Larger Build Targets
Date: Fri, 27 Aug 2021 16:46:33 +0200 [thread overview]
Message-ID: <CAMj1kXFVoSmfSN65dR7gJDAzSPgJWDDbOOhn9=x3HSifP=dUgg@mail.gmail.com> (raw)
In-Reply-To: <3e91ce2b-15c4-d0d7-4ae8-277d61d0c3c6@newmexicoconsortium.org>
(+ Gerd)
On Sat, 21 Aug 2021 at 03:10, Devon Bautista
<dbautista@newmexicoconsortium.org> wrote:
>
> Hello All,
>
> I am currently working with the Linuxboot developers to improve testing kernel + initramfs pairs in firmware using OVMF.
>
> The current maximum image size of an OVMF image is 4MB, which is insufficient for storing even a minimal and compressed kernel and initramfs. To get around this, we've been maintaining our own fork of EDK2 that adds 8MiB and 16MiB OVMF build targets that have enough room in the DXE volume to store a reasonably-sized kernel and initramfs. However, it would be convenient if upstream EDK2 supported these larger OVMF targets.
>
> In discussing this with the previous OVMF maintainer Laszlo Ersek here, it was brought up that:
>
> The trend of the ever-growing DXE-phase warrants a larger firmware volume size
> 8MiB and 16MiB image sizes seem to be justified because of this QEMU commit
>
> However, as Laszlo mentioned, introducing a larger volume size is compatibility breaking, and so seizing the opportunity to come up with a larger non-volatile variable store layout is necessary.
>
> That said, I would like to use this thread to discuss among hardware vendors an optimal variable store layout for these larger image sizes.
>
> Best,
> Devon
> For reference, here is a summary of which sections increased when the 4MiB build target was added (taken from commit b24fca05) after the previous 2MiB limit:
>
> Description Compression type Size [KB]
> ------------------------- ----------------- ----------------------
> Non-volatile data storage open-coded binary 128 -> 528 ( +400)
> data
> Variable store 56 -> 256 ( +200)
> Event log 4 -> 4 ( +0)
> Working block 4 -> 4 ( +0)
> Spare area 64 -> 264 ( +200)
>
> FVMAIN_COMPACT uncompressed 1712 -> 3360 (+1648)
> FV FFS file LZMA compressed
> PEIFV uncompressed 896 -> 896 ( +0)
> individual PEI uncompressed
> modules
> DXEFV uncompressed 10240 -> 10240 ( +0)
> individual DXE uncompressed
> modules
>
> SECFV uncompressed 208 -> 208 ( +0)
> SEC driver
> reset vector code
>
next prev parent reply other threads:[~2021-08-27 14:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-21 1:10 OVMF: NV Variable Store Layout of Larger Build Targets Devon Bautista
2021-08-21 1:17 ` [edk2-devel] " Devon Bautista
2021-08-27 14:46 ` Ard Biesheuvel [this message]
2021-08-30 6:45 ` Gerd Hoffmann
2021-08-30 17:52 ` Devon Bautista
2021-08-30 21:14 ` Andrew Fish
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='CAMj1kXFVoSmfSN65dR7gJDAzSPgJWDDbOOhn9=x3HSifP=dUgg@mail.gmail.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