[edk2-devel] [PATCH] OvmfPkg: raise DXEFV size to 14.5 MB in the traditional platform FDFs
Yao, Jiewen
jiewen.yao at intel.com
Wed Sep 13 11:00:47 UTC 2023
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.yao at intel.com>
> -----Original Message-----
> From: Laszlo Ersek <lersek at redhat.com>
> Sent: Tuesday, September 12, 2023 11:36 PM
> To: Yao, Jiewen <jiewen.yao at intel.com>; Ard Biesheuvel <ardb at kernel.org>
> Cc: devel at edk2.groups.io; Ard Biesheuvel <ardb+tianocore at kernel.org>; Gerd
> Hoffmann <kraxel at redhat.com>; Justen, Jordan L <jordan.l.justen at 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 <ardb at kernel.org>
> >> Sent: Tuesday, September 12, 2023 10:59 PM
> >> To: Laszlo Ersek <lersek at redhat.com>
> >> Cc: devel at edk2.groups.io; Ard Biesheuvel <ardb+tianocore at kernel.org>;
> Gerd
> >> Hoffmann <kraxel at redhat.com>; Yao, Jiewen <jiewen.yao at intel.com>;
> Justen,
> >> Jordan L <jordan.l.justen at 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 <lersek at 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+tianocore at kernel.org>
> >>> Cc: Gerd Hoffmann <kraxel at redhat.com>
> >>> Cc: Jiewen Yao <jiewen.yao at intel.com>
> >>> Cc: Jordan Justen <jordan.l.justen at intel.com>
> >>> Signed-off-by: Laszlo Ersek <lersek at redhat.com>
> >>
> >> Acked-by: Ard Biesheuvel <ardb at 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/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-
More information about the edk2-devel-archive
mailing list