From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from rn-mailsvcp-ppex-lapp14.apple.com (rn-mailsvcp-ppex-lapp14.apple.com [17.179.253.33]) by mx.groups.io with SMTP id smtpd.web10.3257.1630358071815865678 for ; Mon, 30 Aug 2021 14:14:31 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=olVkGNcr; spf=pass (domain: apple.com, ip: 17.179.253.33, mailfrom: afish@apple.com) Received: from pps.filterd (rn-mailsvcp-ppex-lapp14.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp14.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 17ULD8oW011240; Mon, 30 Aug 2021 14:14:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=gLIi9EksB1evHIhdynUd7Yt6MUi3YSLDUz34rhtFYOM=; b=olVkGNcr0x2CSN3wUpEQ/0wZoEUk7H1Zzn//D4zp+H1h3/4v55/mkoCkqEvSSf1VnYOe wxLyvaLuR9qaAgzBFG3Q3835/AWVFDbhmhDpg+thM+lqI6ofLfx6RrrlmDxJJzqZ1SzQ OUdJgs8Zf0qeb7ZjNqK/EPZcgKcux5H/zfUMLt+u3YqVEYMdwcXVLjWGGG1NC4YduOIR 3aLsKulbLaPw5uZgSt2gMZ3n/T5T1jn7/0yd8xJCgg/1wGTh21SGls3+YtAakTcUjtDS 14aQN/b6oDQ7WHUCpjdCbxI+LcNyGmNn2qDsR1tswKQxBuLBCZGavRTVqBzHpO31vWa3 Ww== Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp14.rno.apple.com with ESMTP id 3aqj19e3fn-8 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 30 Aug 2021 14:14:31 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QYO009WO8C72AA0@rn-mailsvcp-mta-lapp04.rno.apple.com>; Mon, 30 Aug 2021 14:14:31 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QYO00Q0087XXF00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 30 Aug 2021 14:14:31 -0700 (PDT) X-Va-A: X-Va-T-CD: 881531e3a5112136e9aad0e8197e0954 X-Va-E-CD: 29f94ecbb496e3c633ac82652579d755 X-Va-R-CD: dcfdf81507458dcc33ee26ce2975ed40 X-Va-CD: 0 X-Va-ID: 1562435d-cbb5-4035-92d4-83ed69b0b75e X-V-A: X-V-T-CD: 881531e3a5112136e9aad0e8197e0954 X-V-E-CD: 29f94ecbb496e3c633ac82652579d755 X-V-R-CD: dcfdf81507458dcc33ee26ce2975ed40 X-V-CD: 0 X-V-ID: 12e8d05e-3511-427d-b433-fa89f6d88fbf X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-08-30_06:2021-08-30,2021-08-30 signatures=0 Received: from [17.235.17.216] (unknown [17.235.17.216]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QYO00FAE8BI6Z00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Mon, 30 Aug 2021 14:14:07 -0700 (PDT) From: "Andrew Fish" Message-id: <4E81CC01-5890-46A2-BBF6-2B3820492F3A@apple.com> MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.1\)) Subject: Re: [edk2-devel] OVMF: NV Variable Store Layout of Larger Build Targets Date: Mon, 30 Aug 2021 14:14:04 -0700 In-reply-to: Cc: Gerd Hoffmann , ardb+tianocore@kernel.org, jiewen.yao@intel.com, Jordan Justen To: edk2-devel-groups-io , dbautista@newmexicoconsortium.org References: <3e91ce2b-15c4-d0d7-4ae8-277d61d0c3c6@newmexicoconsortium.org> <20210830064507.ll6jckr4in6lz3f7@sirius.home.kraxel.org> X-Mailer: Apple Mail (2.3654.20.0.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391,18.0.790 definitions=2021-08-30_06:2021-08-30,2021-08-30 signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_D205CC3D-D953-445C-8ED6-2A3314C2FA8B" --Apple-Mail=_D205CC3D-D953-445C-8ED6-2A3314C2FA8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 30, 2021, at 10:52 AM, Devon Bautista wrote: >=20 > Hi Gerd, >=20 >>> The current maximum image size of an OVMF image is 4MB, which is >>> insufficient for storing even a minimal and compressed kernel and initr= amfs. >>> To get around this, we've been maintaining our own fork of EDK2 that ad= ds >>> 8MiB and 16MiB OVMF build targets that have enough room in the DXE volu= me 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_s= ize()`, but the default maximum if not set is 8MiB. >=20 > So I understand why an 8MiB target is justified, but, like you, I am not = sure if it's really needed. >=20 >>> 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. >>>=20 >>> 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. >>=20 >> The varstore size of the 4M layout is *way* above that (see 2M -> 4M >> commit message): >>=20 >> Variable store 56 -> 256 ( +200) >> Spare area 64 -> 264 ( +200) >>=20 >> 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 straigh= tforward option and is what I would want to go with. >=20 > But I also think that it might make sense when introducing a considerably= larger build target to account for any possible increases in variable stor= e 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 va= rstore enough for vendors? >=20 I=E2=80=99m also in the 16 MiB camp and I=E2=80=99m OK with the 256KiB vars= tore.=20 Thanks, Andrew Fish > --=20 > Best, > Devon >=20 --Apple-Mail=_D205CC3D-D953-445C-8ED6-2A3314C2FA8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Aug 30, 20= 21, at 10:52 AM, Devon Bautista <dbautista@newmexicoconsortium.org> wrote:

Hi Gerd,

Th=
e 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 t=
o
store a reasonably-sized kernel and initramfs. However, it would be
convenient if upstream EDK2 supported these larger OVMF targets.

I'm wondering whe=
never 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. Howev= er, I think Laszlo justified an 8MiB target because the QEMU commit he poin= ted 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, bu= t, like you, I am not sure if it's really needed.

H=
owever, 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 s=
witch 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 la= yout 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 pos= sible increases in variable store size that vendors may expect in the futur= e. I for one dismay any further size increase, but I suppose the more relev= ant question is, is 256KiB of varstore enough for vendors?

I=E2=80=99m also in the 16 MiB camp and I= =E2=80=99m OK with the 256KiB varstore. 

Thanks,

Andrew Fish

-- 
Best,
Devon
=

--Apple-Mail=_D205CC3D-D953-445C-8ED6-2A3314C2FA8B--