public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Gerd Hoffmann" <kraxel@redhat.com>
To: "Xu, Min M" <min.m.xu@intel.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
	"Aktas, Erdem" <erdemaktas@google.com>,
	James Bottomley <jejb@linux.ibm.com>,
	"Yao, Jiewen" <jiewen.yao@intel.com>,
	Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [edk2-devel] [PATCH V1 0/3] Customize lazy-accepted memory size for TDVF
Date: Tue, 17 Jan 2023 10:43:39 +0100	[thread overview]
Message-ID: <20230117094339.dhfaigcftagqiaap@sirius.home.kraxel.org> (raw)
In-Reply-To: <PH0PR11MB5064CA92AD851470D380F077C5C19@PH0PR11MB5064.namprd11.prod.outlook.com>

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


  reply	other threads:[~2023-01-17  9:43 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 ` [PATCH V1 0/3] Customize lazy-accepted memory size for TDVF Gerd Hoffmann
2023-01-16 12:01   ` [edk2-devel] " Min Xu
2023-01-17  9:43     ` Gerd Hoffmann [this message]
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=20230117094339.dhfaigcftagqiaap@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