OvmfPkg/IntelTdx/IntelTdxX64.dsc | 8 ++++ OvmfPkg/Library/PeilessStartupLib/Hob.c | 25 +++++++++---- .../PeilessStartupLib/PeilessStartupLib.inf | 1 + OvmfPkg/Library/PlatformInitLib/IntelTdx.c | 37 ++++++++++++++----- .../PlatformInitLib/PlatformInitLib.inf | 1 + OvmfPkg/OvmfPkg.dec | 2 + OvmfPkg/PlatformPei/MemDetect.c | 13 +++++++ OvmfPkg/PlatformPei/PlatformPei.inf | 1 + 8 files changed, 72 insertions(+), 16 deletions(-)
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4181 Current lazy-accept accepts the memory under address of 4G. To improve boot performance further more, we introduce the feature of customizing the physical end address of lazy-accept in build time. The end address is indicated by PcdAcceptMemoryEndAddress. It means it accepts the memory under PcdAcceptMemoryEndAddress. The default value and the max value is 4G. This is to be consistent with the current rule (accept memory under 4G). In IntelTdxX64 PcdAcceptMemoryEndAddress can be customized on-demand in build-time by adding -D ACCEPT_MEMORY_END_ADDRESS=512 in build command. Code: https://github.com/mxu9/edk2/tree/CustomizeLazyAcceptSize.v1 Cc: Erdem Aktas <erdemaktas@google.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Min Xu <min.m.xu@intel.com> Min M Xu (3): OvmfPkg: Customize lazy-accept's end address OvmfPkg/PeilessStartupLib: Update ConstructFwHobList for lazy-accept OvmfPkg/PlatformPei: Adjust LowerMemorySize in PublishPeiMemory OvmfPkg/IntelTdx/IntelTdxX64.dsc | 8 ++++ OvmfPkg/Library/PeilessStartupLib/Hob.c | 25 +++++++++---- .../PeilessStartupLib/PeilessStartupLib.inf | 1 + OvmfPkg/Library/PlatformInitLib/IntelTdx.c | 37 ++++++++++++++----- .../PlatformInitLib/PlatformInitLib.inf | 1 + OvmfPkg/OvmfPkg.dec | 2 + OvmfPkg/PlatformPei/MemDetect.c | 13 +++++++ OvmfPkg/PlatformPei/PlatformPei.inf | 1 + 8 files changed, 72 insertions(+), 16 deletions(-) -- 2.29.2.windows.2 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97752): https://edk2.groups.io/g/devel/message/97752 Mute This Topic: https://groups.io/mt/95882249/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On 12/25/22 19:33, Min Xu wrote: > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4181 > > Current lazy-accept accepts the memory under address of 4G. To improve > boot performance further more, we introduce the feature of customizing > the physical end address of lazy-accept in build time. > > The end address is indicated by PcdAcceptMemoryEndAddress. It means it > accepts the memory under PcdAcceptMemoryEndAddress. The default value > and the max value is 4G. This is to be consistent with the current rule > (accept memory under 4G). > > In IntelTdxX64 PcdAcceptMemoryEndAddress can be customized on-demand in > build-time by adding -D ACCEPT_MEMORY_END_ADDRESS=512 in build command. Wasn't there an agreement against modifying the build environment like this for memory acceptance? I realize this is not an accept / no-accept build environment change, but still... Thanks, Tom > > Code: https://github.com/mxu9/edk2/tree/CustomizeLazyAcceptSize.v1 > > Cc: Erdem Aktas <erdemaktas@google.com> > Cc: Gerd Hoffmann <kraxel@redhat.com> > Cc: James Bottomley <jejb@linux.ibm.com> > Cc: Jiewen Yao <jiewen.yao@intel.com> > Cc: Tom Lendacky <thomas.lendacky@amd.com> > Signed-off-by: Min Xu <min.m.xu@intel.com> > > Min M Xu (3): > OvmfPkg: Customize lazy-accept's end address > OvmfPkg/PeilessStartupLib: Update ConstructFwHobList for lazy-accept > OvmfPkg/PlatformPei: Adjust LowerMemorySize in PublishPeiMemory > > OvmfPkg/IntelTdx/IntelTdxX64.dsc | 8 ++++ > OvmfPkg/Library/PeilessStartupLib/Hob.c | 25 +++++++++---- > .../PeilessStartupLib/PeilessStartupLib.inf | 1 + > OvmfPkg/Library/PlatformInitLib/IntelTdx.c | 37 ++++++++++++++----- > .../PlatformInitLib/PlatformInitLib.inf | 1 + > OvmfPkg/OvmfPkg.dec | 2 + > OvmfPkg/PlatformPei/MemDetect.c | 13 +++++++ > OvmfPkg/PlatformPei/PlatformPei.inf | 1 + > 8 files changed, 72 insertions(+), 16 deletions(-) > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97881): https://edk2.groups.io/g/devel/message/97881 Mute This Topic: https://groups.io/mt/95882249/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Mon, Dec 26, 2022 at 09:33:35AM +0800, Min Xu wrote: > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4181 > > Current lazy-accept accepts the memory under address of 4G. To improve > boot performance further more, we introduce the feature of customizing > the physical end address of lazy-accept in build time. Do you have numbers? I'm wondering how much of a difference this actually is, given that 2M pages is fast and tdx already uses all processors to accept memory ... What happens in case the firmware runs out of memory in DXE phase? We have MemoryAcceptProtocol meanwhile, but I don't think the memory core uses that to accept more memory on demand (for example when booting linux with a large initrd). take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#97830): https://edk2.groups.io/g/devel/message/97830 Mute This Topic: https://groups.io/mt/95882249/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On January 2, 2023 6:37 PM, Gerd Hoffmann wrote: > On Mon, Dec 26, 2022 at 09:33:35AM +0800, Min Xu wrote: > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4181 > > > > Current lazy-accept accepts the memory under address of 4G. To improve > > boot performance further more, we introduce the feature of customizing > > the physical end address of lazy-accept in build time. > > Do you have numbers? I'm wondering how much of a difference this actually > is, given that 2M pages is fast and tdx already uses all processors to accept > memory ... This feature is tested in Intel SPR platform (boot up a td guest configured with 4vCPU + 4G memory). It costs about 91ms to accept memories under address of 0x20000000. As a comparison it costs about 240ms to accept memories under address of 0x100000000. > > What happens in case the firmware runs out of memory in DXE phase? We create an initrd which size is 881MB. The td guest is configured to accept memories under address of 0x20000000. 1) Direct boot If we set the boot mode as direct boot, then it will turn to next boot option. In our case it is a grub boot. If the log message is turned on, then we can see below errors when trying to FetchBlob "initrd": AllocatePoolPages: failed to allocate 225423 pages AllocatePool: failed to allocate 923331624 bytes FetchBlob: failed to allocate 923331584 bytes for "initrd" Error: Image at 0001E152000 start failed: Out of Resources 2) Grub boot If we set the boot mode as grub boot, then below error message is shown: error: ../../grub-core/loader/i386/efi/linux.c:119:can't allocate initrd. error: ../../grub-core/loader/i386/efi/linux.c:119:can't allocate initrd. Press any key to continue...Press any key to continue... After a while the boot process continued. Finally the td guest is successfully brought up. Thanks Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98570): https://edk2.groups.io/g/devel/message/98570 Mute This Topic: https://groups.io/mt/95882249/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On Mon, Jan 16, 2023 at 12:01:40PM +0000, Xu, Min M wrote: > On January 2, 2023 6:37 PM, Gerd Hoffmann wrote: > > On Mon, Dec 26, 2022 at 09:33:35AM +0800, Min Xu wrote: > > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4181 > > > > > > Current lazy-accept accepts the memory under address of 4G. To improve > > > boot performance further more, we introduce the feature of customizing > > > the physical end address of lazy-accept in build time. > > > > Do you have numbers? I'm wondering how much of a difference this actually > > is, given that 2M pages is fast and tdx already uses all processors to accept > > memory ... > This feature is tested in Intel SPR platform (boot up a td guest configured with 4vCPU + 4G memory). > It costs about 91ms to accept memories under address of 0x20000000. As a comparison it costs about 240ms to accept memories under address of 0x100000000. Under 0x100000000 is 2G in practice with the default q35 memory layout. Under 0x020000000 is 512M (implemented by this patch series). Accepting 4x the memory takes less than 4x the time, probably because some memory is not accepted in multiprocessor mode; or maybe other constant overhead. Accepting additional 1.5G needs ~150 ms, so we talk about ~0.1s per GB. > > What happens in case the firmware runs out of memory in DXE phase? > We create an initrd which size is 881MB. The td guest is configured to accept memories under address of 0x20000000. > 1) Direct boot > [ ... ] > Error: Image at 0001E152000 start failed: Out of Resources > > 2) Grub boot > error: ../../grub-core/loader/i386/efi/linux.c:119:can't allocate initrd. > After a while the boot process continued. Finally the td guest is successfully brought up. I wouldn't call not being able to load the initrd a success. So we can't accept more memory on demand in case 512 MB is not enough. IIRC the last time this was discussed we agreed on accepting all memory below 4G for this reason, and also to keep things simple and give the loaded kernel some wiggle room. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#98660): https://edk2.groups.io/g/devel/message/98660 Mute This Topic: https://groups.io/mt/95882249/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2024 Red Hat, Inc.