<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><font face="Roboto Slab">Hi Gerd,</font><br>
</p>
<blockquote type="cite"
cite="mid:20210830064507.ll6jckr4in6lz3f7@sirius.home.kraxel.org">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I'm wondering whenever it makes sense to have the 8M option. I think
I'd tend to go straight to 16M (which is the max size we can do on x86).
</pre>
</blockquote>
<p><font face="Roboto Slab">On the Linuxboot side, we really only
need 16MiB. However, I think Laszlo justified an 8MiB target
because the QEMU commit he pointed to (referenced in my initial
post) increased the absolute firmware size limit to be 16MiB
when setting the maximum (`pcms->max_fw_size`) in
`pc_machine_set_max_fw_size()`, but the default maximum if not
set is 8MiB.<br>
</font></p>
<p><font face="Roboto Slab">So I understand why an 8MiB target is
justified, but, like you, I am not sure if it's really needed.</font>
</p>
<blockquote type="cite"
cite="mid:20210830064507.ll6jckr4in6lz3f7@sirius.home.kraxel.org">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
The 2M -> 4M switch happened because the varstore was too small. It was
Confirm64KilobytesOfUnauthenticatedVariableStorage test of the the
Microsoft Hardware Certification failing. I guess Microsoft has good
reasons to test for 64k varstore, probably they expect this is big
enough in practice.
The varstore size of the 4M layout is *way* above that (see 2M -> 4M
commit message):
Variable store 56 -> 256 ( +200)
Spare area 64 -> 264 ( +200)
Assuming 256k varstore is more than enough: Sticking to the 4M variable
store layout for the 16M (and maybe 8M) builds looks like the best
option to me. I think the varstore would be identical for 4M and 16M
builds then, so it should be possible to switch guests from 4M to 16M
while keeping the varstore.</pre>
</blockquote>
<p><font face="Roboto Slab">Keeping the 4MiB varstore layout would
be the most compatible and straightforward option and is what I
would want to go with.</font></p>
<p><font face="Roboto Slab">But I also think that it might make
sense when introducing a considerably larger build target to
account for any possible increases in variable store size that
vendors may expect in the future. I for one dismay any further
size increase, but I suppose the more relevant question is, is
256KiB of varstore enough for vendors?<br>
</font></p>
<div class="moz-signature">-- <br>
<style>
div {font-family:'Roboto Slab';}</style>Best,</div>
<div class="moz-signature">Devon<br>
</div>
</body>
</html>
<div width="1" style="color:white;clear:both">_._,_._,_</div> <hr> Groups.io Links:<p> You receive all messages sent to this group. <p> <a target="_blank" href="https://edk2.groups.io/g/devel/message/79958">View/Reply Online (#79958)</a> | | <a target="_blank" href="https://groups.io/mt/85034796/1813853">Mute This Topic</a> | <a href="https://edk2.groups.io/g/devel/post">New Topic</a><br> <a href="https://edk2.groups.io/g/devel/editsub/1813853">Your Subscription</a> | <a href="mailto:devel+owner@edk2.groups.io">Contact Group Owner</a> | <a href="https://edk2.groups.io/g/devel/unsub">Unsubscribe</a> [edk2-devel-archive@redhat.com]<br> <div width="1" style="color:white;clear:both">_._,_._,_</div>