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

Tested with:
- IA32, q35, SMM_REQUIRE, Fedora 30 guest
- X64, pc (i440fx), no SMM, RHEL-7.9 guest
- IA32X64, q35, SMM_REQUIRE, RHEL-7.9 guest

Test steps (IA32 and X64):
- configure 3 VCPUs
- boot
- run "taskset -c $I efibootmgr" with $I covering 0..2
- systemctl suspend
- resume from virt-manager
- run "taskset -c $I efibootmgr" with $I covering 0..2

Test steps (IA32X64):
- same, but
- start with only 2 cold-plugged CPUs, and
- hot-plug the third VCPU after initial (cold) boot, before the first
  "taskset -c $I efibootmgr" invocation

Also compared the verbose IA32 fw log from before the patch vs. the one
after (because IA32 builds even without this patch); the changes look
sane:

> @@ -1,6 +1,6 @@
>  SecCoreStartupWithStack(0xFFFCC000, 0x820000)
>  SEC: Normal boot
> -DecompressMemFvs: OutputBuffer@A00000+0xDE0090 ScratchBuffer@1800000+0x10000 PcdOvmfDecompressionScratchEnd=0x1810000
> +DecompressMemFvs: OutputBuffer@A00000+0xF60090 ScratchBuffer@1A00000+0x10000 PcdOvmfDecompressionScratchEnd=0x1A10000
>  Register PPI Notify: [EfiPeiSecurity2Ppi]
>  Install PPI: [EfiFirmwareFileSystem2]
>  Install PPI: [EfiFirmwareFileSystem3]
> @@ -28,7 +28,7 @@
>  Loading PEIM at 0x000008490C0 EntryPoint=0x0000085639A PlatformPei.efi
>  Platform PEIM Loaded
>  CMOS:
> -00: 10 00 30 00 13 00 03 12 09 23 26 02 00 80 00 00
> +00: 20 00 41 00 13 00 03 12 09 23 26 02 00 80 00 00
>  10: 00 00 00 00 06 80 02 FF FF 00 00 00 00 00 00 00
>  20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>  30: FF FF 20 00 00 7F 00 20 30 00 00 00 00 12 00 00
> @@ -70,7 +70,7 @@
>  Platform PEI Firmware Volume Initialization
>  Install PPI: [EfiPeiFirmwareVolumeInfoPpi]
>  Notify: PPI Guid: [EfiPeiFirmwareVolumeInfoPpi], Peim notify entry point: 826554
> -The 1th FV start address is 0x00000900000, size is 0x00D00000, handle is 0x900000
> +The 1th FV start address is 0x00000900000, size is 0x00E80000, handle is 0x900000
>  Register PPI Notify: [EfiPeiReadOnlyVariable2Ppi]
>  Select Item: 0x19
>  Select Item: 0x26
> @@ -90,8 +90,8 @@
>  Memory Allocation 0x00000000 0x7F000000 - 0x7FFFFFFF
>  Memory Allocation 0x00000000 0x30000 - 0x4FFFF
>  Memory Allocation 0x0000000A 0x820000 - 0x8FFFFF
> -Memory Allocation 0x0000000A 0x900000 - 0x15FFFFF
> -Memory Allocation 0x0000000A 0x1600000 - 0x180FFFF
> +Memory Allocation 0x0000000A 0x900000 - 0x177FFFF
> +Memory Allocation 0x0000000A 0x1780000 - 0x1A0FFFF
>  Memory Allocation 0x00000000 0xE0000000 - 0xEFFFFFFF
>  Old Stack size 32768, New stack size 131072
>  Stack Hob: BaseAddress=0x7AF68000 Length=0x20000
> @@ -196,8 +196,8 @@
>  Memory Allocation 0x00000000 0x7F000000 - 0x7FFFFFFF
>  Memory Allocation 0x00000000 0x30000 - 0x4FFFF
>  Memory Allocation 0x0000000A 0x820000 - 0x8FFFFF
> -Memory Allocation 0x0000000A 0x900000 - 0x15FFFFF
> -Memory Allocation 0x0000000A 0x1600000 - 0x180FFFF
> +Memory Allocation 0x0000000A 0x900000 - 0x177FFFF
> +Memory Allocation 0x0000000A 0x1780000 - 0x1A0FFFF
>  Memory Allocation 0x00000000 0xE0000000 - 0xEFFFFFFF
>  Memory Allocation 0x00000004 0x7EE50000 - 0x7EE6FFFF
>  Memory Allocation 0x00000003 0x7EF50000 - 0x7EF67FFF
> @@ -219,7 +219,7 @@
>  Memory Allocation 0x00000003 0x7EE70000 - 0x7EEB2FFF
>  Memory Allocation 0x00000004 0x7EE50000 - 0x7EE6FFFF
>  Memory Allocation 0x00000004 0x7AF68000 - 0x7AF87FFF
> -FV Hob            0x900000 - 0x15FFFFF
> +FV Hob            0x900000 - 0x177FFFF
>  InstallProtocolInterface: [EfiDecompressProtocol] 7EEAAA54
>  InstallProtocolInterface: [EfiFirmwareVolumeBlockProtocol|EfiFirmwareVolumeBlock2Protocol] 7EB3491C
>  InstallProtocolInterface: [EfiDevicePathProtocol] 7EB34990
> @@ -3259,7 +3259,7 @@
>  UefiMemory protection: 0x50000 - 0x9E000 Success
>  UefiMemory protection: 0x100000 - 0x807000 Success
>  UefiMemory protection: 0x808000 - 0x810000 Success
> -UefiMemory protection: 0x1810000 - 0x7AF88000 Success
> +UefiMemory protection: 0x1A10000 - 0x7AF88000 Success
>  UefiMemory protection: 0x7AF8B000 - 0x7EB3D000 Success
>  UefiMemory protection: 0x7EDBD000 - 0x7EDCF000 Success
>  UefiMemory protection: 0x7EE4F000 - 0x7EF68000 Success

Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 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|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
@@ -86,7 +86,7 @@ [FD.MEMFD]
 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
 FV = PEIFV
 
-0x100000|0xD00000
+0x100000|0xE80000
 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.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|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
@@ -86,7 +86,7 @@ [FD.MEMFD]
 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
 FV = PEIFV
 
-0x100000|0xD00000
+0x100000|0xE80000
 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.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|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
@@ -101,7 +101,7 @@ [FD.MEMFD]
 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
 FV = PEIFV
 
-0x100000|0xD00000
+0x100000|0xE80000
 gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
 FV = DXEFV
 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108535): https://edk2.groups.io/g/devel/message/108535
Mute This Topic: https://groups.io/mt/101315785/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

On Tue, Sep 12, 2023 at 04:18:49PM +0200, 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).

Acked-by: Gerd Hoffmann <kraxel@redhat.com>



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108769): https://edk2.groups.io/g/devel/message/108769
Mute This Topic: https://groups.io/mt/101315785/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

On Tue, 12 Sept 2023 at 16:19, Laszlo Ersek <lersek@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@kernel.org>
> Cc: Gerd Hoffmann <kraxel@redhat.com>
> Cc: Jiewen Yao <jiewen.yao@intel.com>
> Cc: Jordan Justen <jordan.l.justen@intel.com>
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>

Acked-by: Ard Biesheuvel <ardb@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|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> @@ -86,7 +86,7 @@ [FD.MEMFD]
>  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
>  FV = PEIFV
>
> -0x100000|0xD00000
> +0x100000|0xE80000
>  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.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|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> @@ -86,7 +86,7 @@ [FD.MEMFD]
>  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
>  FV = PEIFV
>
> -0x100000|0xD00000
> +0x100000|0xE80000
>  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.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|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesSize
> @@ -101,7 +101,7 @@ [FD.MEMFD]
>  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvSize
>  FV = PEIFV
>
> -0x100000|0xD00000
> +0x100000|0xE80000
>  gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvSize
>  FV = DXEFV
>


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108539): https://edk2.groups.io/g/devel/message/108539
Mute This Topic: https://groups.io/mt/101315785/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

Hello
I do not object the size increase.

I am wondering if we need to take some action to control the size.
Or we just increase it, again and again? Of course, more feature == more size required.

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?

Thank you
Yao, Jiewen

> -----Original Message-----
> From: Ard Biesheuvel <ardb@kernel.org>
> Sent: Tuesday, September 12, 2023 10:59 PM
> To: Laszlo Ersek <lersek@redhat.com>
> Cc: devel@edk2.groups.io; Ard Biesheuvel <ardb+tianocore@kernel.org>; Gerd
> Hoffmann <kraxel@redhat.com>; Yao, Jiewen <jiewen.yao@intel.com>; Justen,
> Jordan L <jordan.l.justen@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@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@kernel.org>
> > Cc: Gerd Hoffmann <kraxel@redhat.com>
> > Cc: Jiewen Yao <jiewen.yao@intel.com>
> > Cc: Jordan Justen <jordan.l.justen@intel.com>
> > Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> 
> Acked-by: Ard Biesheuvel <ardb@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 (#108541): https://edk2.groups.io/g/devel/message/108541
Mute This Topic: https://groups.io/mt/101315785/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

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@kernel.org>
>> Sent: Tuesday, September 12, 2023 10:59 PM
>> To: Laszlo Ersek <lersek@redhat.com>
>> Cc: devel@edk2.groups.io; Ard Biesheuvel <ardb+tianocore@kernel.org>; Gerd
>> Hoffmann <kraxel@redhat.com>; Yao, Jiewen <jiewen.yao@intel.com>; Justen,
>> Jordan L <jordan.l.justen@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@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@kernel.org>
>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>> Cc: Jiewen Yao <jiewen.yao@intel.com>
>>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>>
>> Acked-by: Ard Biesheuvel <ardb@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/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3901457/1787277/102458076/xyzzy [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

  Hi,

> 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.

Yes, it's openssl 3.

> 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.)

Played with the crypto driver a while back, guess I should undust those
patches and resend them.

IIRC the crypto driver is not useful for PEI (size increase), but can be
useful for DXE:  The driver is large but it is a net win nevertheless in
case there is more than one user, i.e. builds with both TLS and secure
boot support enabled.

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108768): https://edk2.groups.io/g/devel/message/108768
Mute This Topic: https://groups.io/mt/101315785/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-

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@intel.com>



> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Tuesday, September 12, 2023 11:36 PM
> To: Yao, Jiewen <jiewen.yao@intel.com>; Ard Biesheuvel <ardb@kernel.org>
> Cc: devel@edk2.groups.io; Ard Biesheuvel <ardb+tianocore@kernel.org>; Gerd
> Hoffmann <kraxel@redhat.com>; Justen, Jordan L <jordan.l.justen@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@kernel.org>
> >> Sent: Tuesday, September 12, 2023 10:59 PM
> >> To: Laszlo Ersek <lersek@redhat.com>
> >> Cc: devel@edk2.groups.io; Ard Biesheuvel <ardb+tianocore@kernel.org>;
> Gerd
> >> Hoffmann <kraxel@redhat.com>; Yao, Jiewen <jiewen.yao@intel.com>;
> Justen,
> >> Jordan L <jordan.l.justen@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@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@kernel.org>
> >>> Cc: Gerd Hoffmann <kraxel@redhat.com>
> >>> Cc: Jiewen Yao <jiewen.yao@intel.com>
> >>> Cc: Jordan Justen <jordan.l.justen@intel.com>
> >>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> >>
> >> Acked-by: Ard Biesheuvel <ardb@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/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-