[edk2-devel] [PATCH] OvmfPkg: raise DXEFV size to 14.5 MB in the traditional platform FDFs

Tue Sep 12 15:35:46 UTC 2023

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 (#108545): https://edk2.groups.io/g/devel/message/108545
Mute This Topic: https://groups.io/mt/101315785/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3943202/1813853/130120423/xyzzy [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-