Thanks Laszlo for the detail explanation, appreciate that. I hope people will take action when it is close to 16MiB, then.
Anyway, I am OK with this so far. Acked-by: Jiewen Yao <jiewen....@intel.com> > -----Original Message----- > From: Laszlo Ersek <ler...@redhat.com> > Sent: Tuesday, September 12, 2023 11:36 PM > To: Yao, Jiewen <jiewen....@intel.com>; Ard Biesheuvel <a...@kernel.org> > Cc: devel@edk2.groups.io; Ard Biesheuvel <ardb+tianoc...@kernel.org>; Gerd > Hoffmann <kra...@redhat.com>; Justen, Jordan L <jordan.l.jus...@intel.com> > Subject: Re: [PATCH] OvmfPkg: raise DXEFV size to 14.5 MB in the traditional > platform FDFs > > On 9/12/23 17:02, Yao, Jiewen wrote: > > Hello > > I do not object the size increase. > > > > I am wondering if we need to take some action to control the size. > > Yes, stop implementing new edk2 features, at least in the same one > generic firmware binary. :) > > > Or we just increase it, again and again? Of course, more feature == > > more size required. > > Exactly. > > DXEFV usage used to grow by 1MB every 20 months or so. > > In particular I suspect (but have no proof) that the OpenSSL 3.0 update > led to a size explosion. This latest increase both comes sooner and is > larger than the previous ones. > > It could likely be mitigated by including the crypto driver in OVMF (as > opposed to linking openssl into every driver statically). But that just > re-raises the age-old question: how do you find the minimal openssl > service *set*, for the crypto driver, such that at OVMF runtime, all > service requests can be satisfied? > > (And, including the full crypto service set in the crypto DXE driver is > much worse than the current state (= static linking) -- I think I once > tested that, and the crypto DXE driver ended up so big that it > outweighed the static linking savings on all the other DXE drivers > combined. So trimming the feature set in the crypto DXE driver is > essential, but I don't know how it can be made *guaranteed* safe.) > > Of course we can also say, "if you need a NOOPT build for debugging a > particular module, then do not include superfluous feaures (with the -D > flag) in your debug build". I.e., declare that a NOOPT build requires > trimming the -D feature flags. > > It would diverge from the tradition, but I guess it should be possible > too (I've not tested it though -- OpenSSL may be used so widely at this > point in edk2 modules that removing some -D flags may not matter in > practice, for saving space). > > > May I know if there is up-limit from VMM perspective, such as KVM? > > E.g. Can we support more than 16MiB ? More than 128MiB? > > Well, QEMU currently has a limitation that the combined size of the > pflash chips (binary+varstore) cannot exceed 8 MiB. But, that can be > overridden on the command line, using the "max-fw-size" machine > property. > > The hard limit is currently 16 MiB (see pc_machine_set_max_fw_size() in > QEMU's "hw/i386/pc.c"). > > I think HP uses a custom OVMF build that is larger than 8 MiB; see QEMU > commit 0657c657eb37. (Note however that said limit refers to the > *compressed* size, while here we're increasing the uncompressed size. > More on this below:) > > But, I think there may be an earlier limit of sorts: > > We can keep increasing DXEFV for a while, because the LZMA compression > in FVMAIN_COMPACT mitigates it. (See edk2 commit b24fca05751f for a > schematic.) But once we outgrow the space allotted for FVMAIN_COMPACT > (3360 KB), there could be an ugly surprise. I've not checked closely, > but growing FVMAIN_COMPACT might lead to such PCD changes that would > break compatibility between existent varstore files and new OVMF > binaries (similarly to how growing the varstore is a compatibility > breaking change). So at least Linux distros need to be aware of that. > > Right now, with this patch, my IA32X64 NOOPT build prints: > > SECFV [26%Full] 212992 (0x34000) total, 56976 (0xde90) used, 156016 (0x26170) > free > PEIFV [77%Full] 917504 (0xe0000) total, 710968 (0xad938) used, 206536 > (0x326c8) free > DXEFV [96%Full] 15204352 (0xe80000) total, 14610736 (0xdef130) used, 593616 > (0x90ed0) free > FVMAIN_COMPACT [69%Full] 3440640 (0x348000) total, 2383312 (0x245dd0) > used, 1057328 (0x102230) free > > So we have still quite some room in FVMAIN_COMPACT. I think it would > allow for an absolutely huge (uncompressed) DXEFV if we wanted to grow > the compressed FVMAIN_COMPACT to the QEMU-permitted hard limit, that is, > nearly 16 MiB. > > Laszlo > > > > > Thank you > > Yao, Jiewen > > > >> -----Original Message----- > >> From: Ard Biesheuvel <a...@kernel.org> > >> Sent: Tuesday, September 12, 2023 10:59 PM > >> To: Laszlo Ersek <ler...@redhat.com> > >> Cc: devel@edk2.groups.io; Ard Biesheuvel <ardb+tianoc...@kernel.org>; > Gerd > >> Hoffmann <kra...@redhat.com>; Yao, Jiewen <jiewen....@intel.com>; > Justen, > >> Jordan L <jordan.l.jus...@intel.com> > >> Subject: Re: [PATCH] OvmfPkg: raise DXEFV size to 14.5 MB in the > >> traditional > >> platform FDFs > >> > >> On Tue, 12 Sept 2023 at 16:19, Laszlo Ersek <ler...@redhat.com> wrote: > >>> > >>> My usual IA32X64 and X64 builds fail for the NOOPT target, using GCC5: > >>> > >>> - IA32X64: > >>> > >>>> the required fv image size 0xdef130 exceeds the set fv image size > >>>> 0xd00000 > >>> > >>> - X64: > >>> > >>>> the required fv image size 0xd8f7b8 exceeds the set fv image size > >>>> 0xd00000 > >>> > >>> NOOPT is important for debugging (less confusing behavior with gdb, and > >>> much less confusing disassembly). > >>> > >>> Raise the DXEFV size to 14.5 MB (14 MB would work, but cut it too close > >>> for IA32X64). > >>> > >>> After this patch: > >>> > >>> - IA32: > >>> > >>>> DXEFV [83%Full] 15204352 (0xe80000) total, 12718784 (0xc212c0) used, > >>>> 2485568 (0x25ed40) free > >>> > >>> - IA32X64: > >>> > >>>> DXEFV [96%Full] 15204352 (0xe80000) total, 14610736 (0xdef130) used, > >>>> 593616 (0x90ed0) free > >>> > >>> - X64: > >>> > >>>> DXEFV [93%Full] 15204352 (0xe80000) total, 14219192 (0xd8f7b8) used, > >>>> 985160 (0xf0848) free > >>> > >> ... > >>> > >>> Cc: Ard Biesheuvel <ardb+tianoc...@kernel.org> > >>> Cc: Gerd Hoffmann <kra...@redhat.com> > >>> Cc: Jiewen Yao <jiewen....@intel.com> > >>> Cc: Jordan Justen <jordan.l.jus...@intel.com> > >>> Signed-off-by: Laszlo Ersek <ler...@redhat.com> > >> > >> Acked-by: Ard Biesheuvel <a...@kernel.org> > >> > >>> --- > >>> OvmfPkg/OvmfPkgIa32.fdf | 6 +++--- > >>> OvmfPkg/OvmfPkgIa32X64.fdf | 6 +++--- > >>> OvmfPkg/OvmfPkgX64.fdf | 6 +++--- > >>> 3 files changed, 9 insertions(+), 9 deletions(-) > >>> > >>> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf > >>> index 4c9be963a74d..383613e54b14 100644 > >>> --- a/OvmfPkg/OvmfPkgIa32.fdf > >>> +++ b/OvmfPkg/OvmfPkgIa32.fdf > >>> @@ -62,10 +62,10 @@ [FD.OVMF_CODE] > >>> > >>> [FD.MEMFD] > >>> BaseAddress = $(MEMFD_BASE_ADDRESS) > >>> -Size = 0xE00000 > >>> +Size = 0xF80000 > >>> ErasePolarity = 1 > >>> BlockSize = 0x10000 > >>> -NumBlocks = 0xE0 > >>> +NumBlocks = 0xF8 > >>> > >>> 0x000000|0x006000 > >>> > >> > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgToken > >> SpaceGuid.PcdOvmfSecPageTablesSize > >>> @@ -86,7 +86,7 @@ [FD.MEMFD] > >>> > >> > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpa > >> ceGuid.PcdOvmfPeiMemFvSize > >>> FV = PEIFV > >>> > >>> -0x100000|0xD00000 > >>> +0x100000|0xE80000 > >>> > >> > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpa > >> ceGuid.PcdOvmfDxeMemFvSize > >>> FV = DXEFV > >>> > >>> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf > >>> index 7f599f15e341..3cec3d0c8790 100644 > >>> --- a/OvmfPkg/OvmfPkgIa32X64.fdf > >>> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf > >>> @@ -62,10 +62,10 @@ [FD.OVMF_CODE] > >>> > >>> [FD.MEMFD] > >>> BaseAddress = $(MEMFD_BASE_ADDRESS) > >>> -Size = 0xE00000 > >>> +Size = 0xF80000 > >>> ErasePolarity = 1 > >>> BlockSize = 0x10000 > >>> -NumBlocks = 0xE0 > >>> +NumBlocks = 0xF8 > >>> > >>> 0x000000|0x006000 > >>> > >> > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgToken > >> SpaceGuid.PcdOvmfSecPageTablesSize > >>> @@ -86,7 +86,7 @@ [FD.MEMFD] > >>> > >> > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpa > >> ceGuid.PcdOvmfPeiMemFvSize > >>> FV = PEIFV > >>> > >>> -0x100000|0xD00000 > >>> +0x100000|0xE80000 > >>> > >> > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpa > >> ceGuid.PcdOvmfDxeMemFvSize > >>> FV = DXEFV > >>> > >>> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf > >>> index 41912fc1bece..9c35b6e848a2 100644 > >>> --- a/OvmfPkg/OvmfPkgX64.fdf > >>> +++ b/OvmfPkg/OvmfPkgX64.fdf > >>> @@ -62,10 +62,10 @@ [FD.OVMF_CODE] > >>> > >>> [FD.MEMFD] > >>> BaseAddress = $(MEMFD_BASE_ADDRESS) > >>> -Size = 0xE00000 > >>> +Size = 0xF80000 > >>> ErasePolarity = 1 > >>> BlockSize = 0x10000 > >>> -NumBlocks = 0xE0 > >>> +NumBlocks = 0xF8 > >>> > >>> 0x000000|0x006000 > >>> > >> > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgToken > >> SpaceGuid.PcdOvmfSecPageTablesSize > >>> @@ -101,7 +101,7 @@ [FD.MEMFD] > >>> > >> > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpa > >> ceGuid.PcdOvmfPeiMemFvSize > >>> FV = PEIFV > >>> > >>> -0x100000|0xD00000 > >>> +0x100000|0xE80000 > >>> > >> > gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpa > >> ceGuid.PcdOvmfDxeMemFvSize > >>> FV = DXEFV > >>> > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#108579): https://edk2.groups.io/g/devel/message/108579 Mute This Topic: https://groups.io/mt/101315785/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
