public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: Min Xu <min.m.xu@intel.com>
Cc: devel@edk2.groups.io, Erdem Aktas <erdemaktas@google.com>,
	James Bottomley <jejb@linux.ibm.com>,
	Jiewen Yao <jiewen.yao@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH V1 0/3] Customize lazy-accepted memory size for TDVF
Date: Mon, 2 Jan 2023 11:36:54 +0100	[thread overview]
Message-ID: <20230102103654.zcpvedhifhqz64r2@sirius.home.kraxel.org> (raw)
In-Reply-To: <20221226013338.1924-1-min.m.xu@intel.com>

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


  parent reply	other threads:[~2023-01-02 10:37 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-26  1:33 [PATCH V1 0/3] Customize lazy-accepted memory size for TDVF Min Xu
2022-12-26  1:33 ` [PATCH V1 1/3] OvmfPkg: Customize lazy-accept's end address Min Xu
2022-12-26  1:33 ` [PATCH V1 2/3] OvmfPkg/PeilessStartupLib: Update ConstructFwHobList for lazy-accept Min Xu
2022-12-26  1:33 ` [PATCH V1 3/3] OvmfPkg/PlatformPei: Adjust LowerMemorySize in PublishPeiMemory Min Xu
2023-01-02 10:36 ` Gerd Hoffmann [this message]
2023-01-16 12:01   ` [edk2-devel] [PATCH V1 0/3] Customize lazy-accepted memory size for TDVF Min Xu
2023-01-17  9:43     ` Gerd Hoffmann
2023-01-03 15:39 ` Lendacky, Thomas

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=20230102103654.zcpvedhifhqz64r2@sirius.home.kraxel.org \
    --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