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.10759.1654598757071429798
 for <devel@edk2.groups.io>;
 Tue, 07 Jun 2022 03:45:57 -0700
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=MP2MHURS;
 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=1654598756;
	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=9tygpLjQsgtCZS0DAIHNHDMv70bdGGNHZGHT7BMyYas=;
	b=MP2MHURSQIWPn6DEfab1U1Mkg5iS69xZ3du5Co/0Pd4nXCpjCOVN2hEGfWIpkvnrkwRLOU
	wX9+g1xbLR/O4GKVCSvirVYV2L2Je18yPgzgz1/5ZGDk3IBBllM3prUUDGK+696u8lBhul
	eSFDbKWI5k1YzvOmK4BzNmxUjSfMoXk=
Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com
 [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS
 (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
 us-mta-124-tLurMKHHP-Sck4QUj3RaWg-1; Tue, 07 Jun 2022 06:45:53 -0400
X-MC-Unique: tLurMKHHP-Sck4QUj3RaWg-1
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mimecast-mx02.redhat.com (Postfix) with ESMTPS id C0D381C3E989;
	Tue,  7 Jun 2022 10:45:52 +0000 (UTC)
Received: from sirius.home.kraxel.org (unknown [10.39.192.40])
	by smtp.corp.redhat.com (Postfix) with ESMTPS id 670A9C27E92;
	Tue,  7 Jun 2022 10:45:52 +0000 (UTC)
Received: by sirius.home.kraxel.org (Postfix, from userid 1000)
	id 4C2E51800081; Tue,  7 Jun 2022 12:45:50 +0200 (CEST)
Date: Tue, 7 Jun 2022 12:45:50 +0200
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 07/14] OvmfPkg: Add PCD and DEFINEs for Lazy Accept page.
Message-ID: <20220607104550.hz6c7etgxtksylwu@sirius.home.kraxel.org>
References: <cover.1654420875.git.min.m.xu@intel.com>
 <cce5ea2aaaeddd9ce9df6fa7ac1ef52976c5c7e6.1654420876.git.min.m.xu@intel.com>
MIME-Version: 1.0
In-Reply-To: <cce5ea2aaaeddd9ce9df6fa7ac1ef52976c5c7e6.1654420876.git.min.m.xu@intel.com>
X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8
Authentication-Results: relay.mimecast.com;
	auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Jun 06, 2022 at 10:59:55AM +0800, Min Xu wrote:
> From: Min M Xu <min.m.xu@intel.com>
> 
> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
> 
> Lazy accept page can be controlled in build time like below:
>   -D LAZY_ACCEPT_PARTIAL_MEM=512
> 
> The unit is MB. If it is 0 then it means Lazy-accept is turned off.
> 
> Lazy-accept is turned off by default in OvmfPkgX64.
> Lazy-accept is turned on with 512MB by default in IntelTdxX64.

Care to explain?  What is the point in not using lazy accept in OvmfPkgX64?
Also what exactly does this option mean?  Is this the minimum amount of
memory accepted by the firmware?

take care,
  Gerd