public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: "Gao, Liming" <liming.gao@intel.com>,
	edk2-devel-01 <edk2-devel@lists.01.org>
Cc: "Justen, Jordan L" <jordan.l.justen@intel.com>,
	Gary Lin <glin@suse.com>,
	 Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [PATCH] OvmfPkg: raise DXEFV size to 11 MB
Date: Tue, 29 May 2018 09:25:33 +0200	[thread overview]
Message-ID: <6c4791f6-edd2-556d-3a4c-4108dab05b0b@redhat.com> (raw)
In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14E28DCE4@SHSMSX104.ccr.corp.intel.com>

Hi Liming,

On 05/29/18 07:25, Gao, Liming wrote:
> Laszlo:
>   OvmfPkgIa32.fdf, OvmfPkgX64.fdf and OvmfPkgIa32X64.fdf are almost same. I suggest to use the single FDF for them. If so, this change is only made once. 
> 
>   For X64 only module in FDF, we can use below style to include it. 
> 
> !if $(E1000_ENABLE) && "X64" in $(ARCH)
>   FILE DRIVER = 5D695E11-9B3F-4b83-B25F-4A8D5D69BE07 {
>     SECTION PE32 = Intel3.5/EFIX64/E3522X2.EFI
>   }
> !endif

right, at some point in time -- "later" :) -- we should extract most
common parts into shared include files. We already do that for a few
things (see "DecomprScratchEnd.fdf.inc", "OvmfPkg.fdf.inc",
"VarStore.fdf.inc"), but more would be possible to extract, indeed.

For now, I prefer to push this patch, because I don't really have time
to embark on the refactoring, and the patch fixes a build issue.

Thanks!
Laszlo


>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Tuesday, May 29, 2018 2:50 AM
>> To: edk2-devel-01 <edk2-devel@lists.01.org>
>> Cc: Justen, Jordan L <jordan.l.justen@intel.com>; Gary Lin <glin@suse.com>;
>> Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Subject: [edk2] [PATCH] OvmfPkg: raise DXEFV size to 11 MB
>>
>> Almost exactly two years after commit 2f7b34b20842f, we've grown out the
>> 10MB DXEFV:
>>
>>> build -a IA32 -a X64 -p OvmfPkg/OvmfPkgIa32X64.dsc -b NOOPT -t GCC48 \
>>>   -D SMM_REQUIRE -D SECURE_BOOT_ENABLE -D TLS_ENABLE -D
>> E1000_ENABLE \
>>>   -D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE
>>>
>>> [...]
>>>
>>> GenFv: ERROR 3000: Invalid
>>>   the required fv image size 0xa28d48 exceeds the set fv image size
>>>   0xa00000
>>
>> Raise the DXEFV size to 11MB.
>>
>> (For builds that don't need this DXEFV bump, I've checked the
>> FVMAIN_COMPACT increase stemming from the additional 1MB padding,
>> using
>> NOOPT + GCC48 + FD_SIZE_2MB, and no other "-D" flags. In the IA32 build,
>> FVMAIN_COMPACT grows by 232 bytes. In the IA32X64 build,
>> FVMAIN_COMPACT
>> shrinks by 64 bytes. In the X64 build, FVMAIN_COMPACT shrinks by 376
>> bytes.)
>>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Gary Lin <glin@suse.com>
>> Cc: Jordan Justen <jordan.l.justen@intel.com>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>>
>> Notes:
>>    - repo & branch: https://github.com/lersek/edk2.git ; dxefv_11mb
>>
>>    - regression-tested with the "crash" tool for vmcore analysis
>>
>>    - regression-tested using S3 suspend/resume with my usual guests,
>>      including Linux, Windows, i440fx, q35, SMM etc
>>
>> 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 0427ded49239..b199713925fe 100644
>> --- a/OvmfPkg/OvmfPkgIa32.fdf
>> +++ b/OvmfPkg/OvmfPkgIa32.fdf
>> @@ -68,10 +68,10 @@ [FD.OVMF_CODE]
>>
>> [FD.MEMFD]
>> BaseAddress   = $(MEMFD_BASE_ADDRESS)
>> -Size          = 0xB00000
>> +Size          = 0xC00000
>> ErasePolarity = 1
>> BlockSize     = 0x10000
>> -NumBlocks     = 0xB0
>> +NumBlocks     = 0xC0
>>
>> 0x000000|0x006000
>>
>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgT
>> okenSpaceGuid.PcdOvmfSecPageTablesSize
>> @@ -89,7 +89,7 @@ [FD.MEMFD]
>>
>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgToke
>> nSpaceGuid.PcdOvmfPeiMemFvSize
>> FV = PEIFV
>>
>> -0x100000|0xA00000
>> +0x100000|0xB00000
>>
>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTok
>> enSpaceGuid.PcdOvmfDxeMemFvSize
>> FV = DXEFV
>>
>> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
>> index 6df47f48cd2c..4ebf64b2b9dc 100644
>> --- a/OvmfPkg/OvmfPkgIa32X64.fdf
>> +++ b/OvmfPkg/OvmfPkgIa32X64.fdf
>> @@ -68,10 +68,10 @@ [FD.OVMF_CODE]
>>
>> [FD.MEMFD]
>> BaseAddress   = $(MEMFD_BASE_ADDRESS)
>> -Size          = 0xB00000
>> +Size          = 0xC00000
>> ErasePolarity = 1
>> BlockSize     = 0x10000
>> -NumBlocks     = 0xB0
>> +NumBlocks     = 0xC0
>>
>> 0x000000|0x006000
>>
>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgT
>> okenSpaceGuid.PcdOvmfSecPageTablesSize
>> @@ -89,7 +89,7 @@ [FD.MEMFD]
>>
>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgToke
>> nSpaceGuid.PcdOvmfPeiMemFvSize
>> FV = PEIFV
>>
>> -0x100000|0xA00000
>> +0x100000|0xB00000
>>
>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTok
>> enSpaceGuid.PcdOvmfDxeMemFvSize
>> FV = DXEFV
>>
>> diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
>> index 2e2a1749b5d2..9ca96f928287 100644
>> --- a/OvmfPkg/OvmfPkgX64.fdf
>> +++ b/OvmfPkg/OvmfPkgX64.fdf
>> @@ -68,10 +68,10 @@ [FD.OVMF_CODE]
>>
>> [FD.MEMFD]
>> BaseAddress   = $(MEMFD_BASE_ADDRESS)
>> -Size          = 0xB00000
>> +Size          = 0xC00000
>> ErasePolarity = 1
>> BlockSize     = 0x10000
>> -NumBlocks     = 0xB0
>> +NumBlocks     = 0xC0
>>
>> 0x000000|0x006000
>>
>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase|gUefiOvmfPkgT
>> okenSpaceGuid.PcdOvmfSecPageTablesSize
>> @@ -89,7 +89,7 @@ [FD.MEMFD]
>>
>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|gUefiOvmfPkgToke
>> nSpaceGuid.PcdOvmfPeiMemFvSize
>> FV = PEIFV
>>
>> -0x100000|0xA00000
>> +0x100000|0xB00000
>>
>> gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDxeMemFvBase|gUefiOvmfPkgTok
>> enSpaceGuid.PcdOvmfDxeMemFvSize
>> FV = DXEFV
>>
>> --
>> 2.14.1.3.gb7cf6e02401b
>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel



  reply	other threads:[~2018-05-29  7:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-28 18:49 [PATCH] OvmfPkg: raise DXEFV size to 11 MB Laszlo Ersek
2018-05-28 18:58 ` Ard Biesheuvel
2018-05-29  3:34 ` Gary Lin
2018-05-29  5:25 ` Gao, Liming
2018-05-29  7:25   ` Laszlo Ersek [this message]
2018-05-29  7:28     ` Gao, Liming
2018-05-29  8:17 ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6c4791f6-edd2-556d-3a4c-4108dab05b0b@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox