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.web11.32649.1672655821586887953
 for <devel@edk2.groups.io>;
 Mon, 02 Jan 2023 02:37:02 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=WmYddhoN;
 spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;
	s=mimecast20190719; t=1672655819;
	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:
	 in-reply-to:in-reply-to:references:references;
	bh=MX3F9NHqIjQMbQmvhfrgGONYI2nCpRqZD6wMhqvtpys=;
	b=WmYddhoNAjGcEYP9/tvlFt+YTW3rCuc6VoKv8m2ESx/GOL6MeL0uGZ/b7XfwCrvEbEE9Hs
	U/k1nkM+yVo/SlQ2uwo0jlsiYHQi+GapbP75i0FWuKq23nlFn8Q+fv9mPnjniBcLiapL7l
	Ok25ANCZf2GmK++8mC/OGTANSQ2BlOg=
Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com
 [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 us-mta-120-2LPCxG0oP26EdixhzXVMrA-1; Mon, 02 Jan 2023 05:36:56 -0500
X-MC-Unique: 2LPCxG0oP26EdixhzXVMrA-1
Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 29C2285A588;
	Mon,  2 Jan 2023 10:36:56 +0000 (UTC)
Received: from sirius.home.kraxel.org (unknown [10.39.192.238])
	by smtp.corp.redhat.com (Postfix) with ESMTPS id EBE54492B06;
	Mon,  2 Jan 2023 10:36:55 +0000 (UTC)
Received: by sirius.home.kraxel.org (Postfix, from userid 1000)
	id 8F68E18003B9; Mon,  2 Jan 2023 11:36:54 +0100 (CET)
Date: Mon, 2 Jan 2023 11:36:54 +0100
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
Message-ID: <20230102103654.zcpvedhifhqz64r2@sirius.home.kraxel.org>
References: <20221226013338.1924-1-min.m.xu@intel.com>
MIME-Version: 1.0
In-Reply-To: <20221226013338.1924-1-min.m.xu@intel.com>
X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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