> On Aug 30, 2021, at 10:52 AM, Devon Bautista > <dbauti...@newmexicoconsortium.org> wrote: > > Hi Gerd, > >>> 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. >> 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). > 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. > > So I understand why an 8MiB target is justified, but, like you, I am not sure > if it's really needed. > >>> 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. >> 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. > Keeping the 4MiB varstore layout would be the most compatible and > straightforward option and is what I would want to go with. > > 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? > I’m also in the 16 MiB camp and I’m OK with the 256KiB varstore.
Thanks, Andrew Fish > -- > Best, > Devon > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#79959): https://edk2.groups.io/g/devel/message/79959 Mute This Topic: https://groups.io/mt/85034796/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
