From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web08.4820.1622110355949494081 for ; Thu, 27 May 2021 03:12:36 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ckzKX6k/; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1622110355; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pgGbiic0eluoSb7JPCK6HUHbxCAhIe7FfmFUYbsjiPg=; b=ckzKX6k/12ya0g0hcmH/wupo29UXFUzcaxV9qM+/05R+Bmx60WOz55xesbP+kDh5Oq3Ve9 oGVNTKTUcDtIJq0l8B02OWu7xqFd21LeGNY0KAhcJYU4O+9Kwah4lY7cND2gGpuhtby1U4 ISwD56Kdf+yhw7g53eiGext+8R5fb0U= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-582-rvKDgifoOsOxL6mujbuquQ-1; Thu, 27 May 2021 06:12:31 -0400 X-MC-Unique: rvKDgifoOsOxL6mujbuquQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 29A4B80ED8E; Thu, 27 May 2021 10:12:30 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-115-44.ams2.redhat.com [10.36.115.44]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1C92E59479; Thu, 27 May 2021 10:12:27 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v1] OvmfPkg: Add build options for 8MB and 16MB X64 OVMF images To: devel@edk2.groups.io, dbautista@newmexicoconsortium.org References: <7bfd4b82fc725302beb37e13c4a89d389c34ec34.1622048433.git.dbautista@newmexicoconsortium.org> From: "Laszlo Ersek" Cc: Brijesh Singh , Erdem Aktas , James Bottomley , Jiewen Yao , Min Xu , Tom Lendacky Message-ID: Date: Thu, 27 May 2021 12:12:26 +0200 MIME-Version: 1.0 In-Reply-To: <7bfd4b82fc725302beb37e13c4a89d389c34ec34.1622048433.git.dbautista@newmexicoconsortium.org> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=lersek@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 05/26/21 19:08, Devon Bautista wrote: > Currently, the largest volume size for building OVMF images is 4MB. With > the growth of the Linuxboot project, maintainers have had to maintain a > fork containing this patch which allows larger image sizes in order for > Linuxboot developers/users to have enough space to experiment with > and test including their own Linux kernel in the DXE section of OVMF > firmware. Testing using OVMF is valuable since it allows testing in QEMU > and thus does not require any hardware to do so. > > This patch allows specifying '-D FD_SIZE_8MB' or '-D FD_SIZE_16MB' to > the OVMF build script in order to add the ability to build 8MB or 16MB > x86_64 (X64) OVMF images, respectively. > > Signed-off-by: Devon Bautista > --- > OvmfPkg/OvmfPkgDefines.fdf.inc | 34 ++++++++++++++++++++++++++++++++++ > OvmfPkg/OvmfPkgX64.dsc | 10 +++++++++- > OvmfPkg/VarStore.fdf.inc | 16 ++++++++-------- > 3 files changed, 51 insertions(+), 9 deletions(-) > > diff --git a/OvmfPkg/OvmfPkgDefines.fdf.inc b/OvmfPkg/OvmfPkgDefines.fdf.inc > index 35fd454b97..da37758934 100644 > --- a/OvmfPkg/OvmfPkgDefines.fdf.inc > +++ b/OvmfPkg/OvmfPkgDefines.fdf.inc > @@ -66,6 +66,40 @@ DEFINE SECFV_OFFSET = 0x003CC000 > DEFINE SECFV_SIZE = 0x34000 > !endif > > +!if $(FD_SIZE_IN_KB) == 8192 > +DEFINE VARS_SIZE = 0x84000 > +DEFINE VARS_BLOCKS = 0x84 > +DEFINE VARS_LIVE_SIZE = 0x40000 > +DEFINE VARS_SPARE_SIZE = 0x42000 > + > +DEFINE FW_BASE_ADDRESS = 0xFF800000 > +DEFINE FW_SIZE = 0x00800000 > +DEFINE FW_BLOCKS = 0x800 > +DEFINE CODE_BASE_ADDRESS = 0xFF884000 > +DEFINE CODE_SIZE = 0x0077C000 > +DEFINE CODE_BLOCKS = 0x77C > +DEFINE FVMAIN_SIZE = 0x00748000 > +DEFINE SECFV_OFFSET = 0x007CC000 > +DEFINE SECFV_SIZE = 0x34000 > +!endif > + > +!if $(FD_SIZE_IN_KB) == 16384 > +DEFINE VARS_SIZE = 0x84000 > +DEFINE VARS_BLOCKS = 0x84 > +DEFINE VARS_LIVE_SIZE = 0x40000 > +DEFINE VARS_SPARE_SIZE = 0x42000 > + > +DEFINE FW_BASE_ADDRESS = 0xFF000000 > +DEFINE FW_SIZE = 0x01000000 > +DEFINE FW_BLOCKS = 0x1000 > +DEFINE CODE_BASE_ADDRESS = 0xFF084000 > +DEFINE CODE_SIZE = 0x00F7C000 > +DEFINE CODE_BLOCKS = 0xF7C > +DEFINE FVMAIN_SIZE = 0x00F48000 > +DEFINE SECFV_OFFSET = 0x00FCC000 > +DEFINE SECFV_SIZE = 0x34000 > +!endif > + > SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFdBaseAddress = $(FW_BASE_ADDRESS) > SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareFdSize = $(FW_SIZE) > SET gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFirmwareBlockSize = $(BLOCK_SIZE) > diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc > index 999738dc39..28351e2f56 100644 > --- a/OvmfPkg/OvmfPkgX64.dsc > +++ b/OvmfPkg/OvmfPkgX64.dsc > @@ -66,11 +66,19 @@ > !else > !ifdef $(FD_SIZE_4MB) > DEFINE FD_SIZE_IN_KB = 4096 > +!else > +!ifdef $(FD_SIZE_8MB) > + DEFINE FD_SIZE_IN_KB = 8192 > +!else > +!ifdef $(FD_SIZE_16MB) > + DEFINE FD_SIZE_IN_KB = 16384 > !else > DEFINE FD_SIZE_IN_KB = 4096 > !endif > !endif > !endif > +!endif > +!endif > > [BuildOptions] > GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG > @@ -501,7 +509,7 @@ > gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize|0xe000 > !endif > !endif > -!if $(FD_SIZE_IN_KB) == 4096 > +!if $(FD_SIZE_IN_KB) == 4096 || $(FD_SIZE_IN_KB) == 8196 || $(FD_SIZE_IN_KB) == 16384 > gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x8400 > gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize|0x8400 > !if $(NETWORK_TLS_ENABLE) == FALSE > diff --git a/OvmfPkg/VarStore.fdf.inc b/OvmfPkg/VarStore.fdf.inc > index a1e524e393..70db929478 100644 > --- a/OvmfPkg/VarStore.fdf.inc > +++ b/OvmfPkg/VarStore.fdf.inc > @@ -11,7 +11,7 @@ > !if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048) > 0x00000000|0x0000e000 > !endif > -!if $(FD_SIZE_IN_KB) == 4096 > +!if ($(FD_SIZE_IN_KB) == 4096) || ($(FD_SIZE_IN_KB) == 8192) || ($(FD_SIZE_IN_KB) == 16384) > 0x00000000|0x00040000 > !endif > #NV_VARIABLE_STORE > @@ -29,7 +29,7 @@ DATA = { > # FvLength: 0x20000 > 0x00, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, > !endif > -!if $(FD_SIZE_IN_KB) == 4096 > +!if ($(FD_SIZE_IN_KB) == 4096) || ($(FD_SIZE_IN_KB) == 8192) || ($(FD_SIZE_IN_KB) == 16384) > # FvLength: 0x84000 > 0x00, 0x40, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, > !endif > @@ -41,7 +41,7 @@ DATA = { > # CheckSum > 0x19, 0xF9, > !endif > -!if $(FD_SIZE_IN_KB) == 4096 > +!if ($(FD_SIZE_IN_KB) == 4096) || ($(FD_SIZE_IN_KB) == 8192) || ($(FD_SIZE_IN_KB) == 16384) > # CheckSum > 0xAF, 0xB8, > !endif > @@ -51,7 +51,7 @@ DATA = { > # Blockmap[0]: 0x20 Blocks * 0x1000 Bytes / Block > 0x20, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, > !endif > -!if $(FD_SIZE_IN_KB) == 4096 > +!if ($(FD_SIZE_IN_KB) == 4096) || ($(FD_SIZE_IN_KB) == 8192) || ($(FD_SIZE_IN_KB) == 16384) > # Blockmap[0]: 0x84 Blocks * 0x1000 Bytes / Block > 0x84, 0x00, 0x00, 0x00, 0x00, 0x10, 0x00, 0x00, > !endif > @@ -70,7 +70,7 @@ DATA = { > # This can speed up the Variable Dispatch a bit. > 0xB8, 0xDF, 0x00, 0x00, > !endif > -!if $(FD_SIZE_IN_KB) == 4096 > +!if ($(FD_SIZE_IN_KB) == 4096) || ($(FD_SIZE_IN_KB) == 8192) || ($(FD_SIZE_IN_KB) == 16384) > # Size: 0x40000 (gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize) - > # 0x48 (size of EFI_FIRMWARE_VOLUME_HEADER) = 0x3ffb8 > # This can speed up the Variable Dispatch a bit. > @@ -83,7 +83,7 @@ DATA = { > !if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048) > 0x0000e000|0x00001000 > !endif > -!if $(FD_SIZE_IN_KB) == 4096 > +!if ($(FD_SIZE_IN_KB) == 4096) || ($(FD_SIZE_IN_KB) == 8192) || ($(FD_SIZE_IN_KB) == 16384) > 0x00040000|0x00001000 > !endif > #NV_EVENT_LOG > @@ -91,7 +91,7 @@ DATA = { > !if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048) > 0x0000f000|0x00001000 > !endif > -!if $(FD_SIZE_IN_KB) == 4096 > +!if ($(FD_SIZE_IN_KB) == 4096) || ($(FD_SIZE_IN_KB) == 8192) || ($(FD_SIZE_IN_KB) == 16384) > 0x00041000|0x00001000 > !endif > #NV_FTW_WORKING > @@ -109,7 +109,7 @@ DATA = { > !if ($(FD_SIZE_IN_KB) == 1024) || ($(FD_SIZE_IN_KB) == 2048) > 0x00010000|0x00010000 > !endif > -!if $(FD_SIZE_IN_KB) == 4096 > +!if ($(FD_SIZE_IN_KB) == 4096) || ($(FD_SIZE_IN_KB) == 8192) || ($(FD_SIZE_IN_KB) == 16384) > 0x00042000|0x00042000 > !endif > #NV_FTW_SPARE > I'm providing minimal feedback here just to get this review off my plate as quickly as possible. Sorry, I'm collapsing under my TODO list. (1) Every such change is compatibility breaking, so we *must* use the opportunity at once to *significantly increase* the non-volatile variable store size as well. We need to discuss this question with OS vendors and hardware platform vendors on this list, to see what physical flash sizes are expected in the future, and we must add a good safety margin on top of that. The primary concern is with the dbx variable growing without bounds over time. Once we introduce a new FD_SIZE_IN_KB option, we're stuck with its varstore layout forever, so we'd better get it right and future-proof at once. (2) [FD.MEMFD] should immediately benefit from this change, even if your downstream populates FVMAIN_COMPACT with something else than PEIFV and DXEFV. First, we're almost out of (uncompressed) DXEFV space again. Second, especially the confidential computing technologies have been gobbling up the nice, low, free space in FD.MEMFD the way a kid with a sweet tooth empties a cookie jar. This change is already compat breaking, so I'd like to see *some* proposal (separate patches) for enlarging *and pushing up* PEIFV and DXEFV. (3) Unfortunately, I have to agree that introducing *both* a 8MB option *and* a 16MB option is justified, per QEMU commit 0657c657eb37 ("hw/i386/pc: add max combined fw size as machine configuration option", 2020-12-09). However, please add each option in a separate patch. (4) Dumping a bunch of magic numbers on reviewers is unhelpful. I'll need to sit down with a calculator and go through the patch with a magnifying glass. Please support that work by creating a commit message (summary table) similar to the one in commit b24fca05751f ("OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK", 2017-05-05). (5) Modifying *only* "OvmfPkg/OvmfPkgX64.dsc" doesn't seem right, there are other DSC files (platforms) in OvmfPkg that would benefit. Without much thinking for now, I'd say the new options should be available in each DSC (platform description), even the 32-bit ones. I'm extremely annoyed by the general trend that the firmware (the OS under the OS) keeps growing. Because of that, Linuxboot is a fantastic project. I'd like OVMF to support the development of Linuxboot. I welcome this patch for that reason. But I'd also like OVMF to benefit from this change even when it is built with a traditional -- and regrettably, ever-growing -- DXE phase. I welcome this patch for that reason too. Thank you, Laszlo