From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 19A7FAC1862 for ; Tue, 12 Sep 2023 15:35:54 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=DKTd+HUYEhiAabuklwHNdXPhkFnM9yk6YahC29IkfIk=; c=relaxed/simple; d=groups.io; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Language:Content-Type:Content-Transfer-Encoding; s=20140610; t=1694532953; v=1; b=anuOYTMe+IIckQlbaWdKCOtu75RXVfTjsx5jkPNvfusIDnsiauAVOtMBpZsCDP1boNu21OHv /YbSw1rcYZswLRfq+n6a8ZceqvWFHn0Yh7fvj/FDtbHmvDxhOrYPQT/D/CIS6H9Du5B+HkmBuI4 p4l3OCOTjIp0Pj+LgqBeBSng= X-Received: by 127.0.0.2 with SMTP id Iis5YY7687511xvqKvvf1dYS; Tue, 12 Sep 2023 08:35:53 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.28581.1694532952990400760 for ; Tue, 12 Sep 2023 08:35:53 -0700 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-617-w-q4RG0MPb2_ISL0jKFzsg-1; Tue, 12 Sep 2023 11:35:50 -0400 X-MC-Unique: w-q4RG0MPb2_ISL0jKFzsg-1 X-Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4F509101FABB; Tue, 12 Sep 2023 15:35:50 +0000 (UTC) X-Received: from [10.39.193.227] (unknown [10.39.193.227]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 83C92728FD; Tue, 12 Sep 2023 15:35:47 +0000 (UTC) Message-ID: <696c06dc-f360-7d8b-b4df-b1f705c64351@redhat.com> Date: Tue, 12 Sep 2023 17:35:46 +0200 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH] OvmfPkg: raise DXEFV size to 14.5 MB in the traditional platform FDFs To: "Yao, Jiewen" , Ard Biesheuvel Cc: "devel@edk2.groups.io" , Ard Biesheuvel , Gerd Hoffmann , "Justen, Jordan L" References: <20230912141849.75147-1-lersek@redhat.com> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,lersek@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: DMsRzT1i4BWt4Ep07uWXMSlmx7686176AA= Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=anuOYTMe; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io 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 =3D=3D > 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 (=3D 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 (0x2617= 0) free PEIFV [77%Full] 917504 (0xe0000) total, 710968 (0xad938) used, 206536 (0x32= 6c8) 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 >> Sent: Tuesday, September 12, 2023 10:59 PM >> To: Laszlo Ersek >> Cc: devel@edk2.groups.io; Ard Biesheuvel ; Ge= rd >> Hoffmann ; Yao, Jiewen ; Justen= , >> Jordan L >> Subject: Re: [PATCH] OvmfPkg: raise DXEFV size to 14.5 MB in the traditi= onal >> platform FDFs >> >> On Tue, 12 Sept 2023 at 16:19, Laszlo Ersek 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 >>> Cc: Gerd Hoffmann >>> Cc: Jiewen Yao >>> Cc: Jordan Justen >>> Signed-off-by: Laszlo Ersek >> >> Acked-by: Ard Biesheuvel >> >>> --- >>> 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 =3D $(MEMFD_BASE_ADDRESS) >>> -Size =3D 0xE00000 >>> +Size =3D 0xF80000 >>> ErasePolarity =3D 1 >>> BlockSize =3D 0x10000 >>> -NumBlocks =3D 0xE0 >>> +NumBlocks =3D 0xF8 >>> >>> 0x000000|0x006000 >>> >> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgToken >> SpaceGuid.PcdOvmfSecPageTablesSize >>> @@ -86,7 +86,7 @@ [FD.MEMFD] >>> >> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpa >> ceGuid.PcdOvmfPeiMemFvSize >>> FV =3D PEIFV >>> >>> -0x100000|0xD00000 >>> +0x100000|0xE80000 >>> >> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpa >> ceGuid.PcdOvmfDxeMemFvSize >>> FV =3D 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 =3D $(MEMFD_BASE_ADDRESS) >>> -Size =3D 0xE00000 >>> +Size =3D 0xF80000 >>> ErasePolarity =3D 1 >>> BlockSize =3D 0x10000 >>> -NumBlocks =3D 0xE0 >>> +NumBlocks =3D 0xF8 >>> >>> 0x000000|0x006000 >>> >> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgToken >> SpaceGuid.PcdOvmfSecPageTablesSize >>> @@ -86,7 +86,7 @@ [FD.MEMFD] >>> >> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpa >> ceGuid.PcdOvmfPeiMemFvSize >>> FV =3D PEIFV >>> >>> -0x100000|0xD00000 >>> +0x100000|0xE80000 >>> >> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpa >> ceGuid.PcdOvmfDxeMemFvSize >>> FV =3D 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 =3D $(MEMFD_BASE_ADDRESS) >>> -Size =3D 0xE00000 >>> +Size =3D 0xF80000 >>> ErasePolarity =3D 1 >>> BlockSize =3D 0x10000 >>> -NumBlocks =3D 0xE0 >>> +NumBlocks =3D 0xF8 >>> >>> 0x000000|0x006000 >>> >> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgToken >> SpaceGuid.PcdOvmfSecPageTablesSize >>> @@ -101,7 +101,7 @@ [FD.MEMFD] >>> >> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpa >> ceGuid.PcdOvmfPeiMemFvSize >>> FV =3D PEIFV >>> >>> -0x100000|0xD00000 >>> +0x100000|0xE80000 >>> >> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpa >> ceGuid.PcdOvmfDxeMemFvSize >>> FV =3D DXEFV >>> > -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- 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/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/19134562= 12/xyzzy [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-