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.web10.3275.1654669092122766485 for ; Tue, 07 Jun 2022 23:18:12 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=D17+q/Rq; 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=1654669091; 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=FJLs70ISra8G1JY1M8jKyQjqvKOJh1tMIZEkOOBUeWI=; b=D17+q/Rq4L4+GNk0e9/TYH3SKAg44sY0b3GkDoR9oacb9mrkhFDVY4eE9PGEG35G2EN+sy tw5ytk3r1Df6Gx/48R8yKTsKY7KVMg/+dB3Ni/92rrQRj1woUkyM2I02ew9OWoMf7YiSGa cryrf54EC52HAkKSc2RzlYQC9tVgAbE= 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-550-CjO1IRDENdWhKAL2bp0FGg-1; Wed, 08 Jun 2022 02:18:07 -0400 X-MC-Unique: CjO1IRDENdWhKAL2bp0FGg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4402829AA3BB; Wed, 8 Jun 2022 06:18:07 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.40]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EC92F18EA2; Wed, 8 Jun 2022 06:18:06 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 7ED6018003AA; Wed, 8 Jun 2022 08:18:05 +0200 (CEST) Date: Wed, 8 Jun 2022 08:18:05 +0200 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , "Aktas, Erdem" , James Bottomley , "Yao, Jiewen" , Tom Lendacky Subject: Re: [PATCH 07/14] OvmfPkg: Add PCD and DEFINEs for Lazy Accept page. Message-ID: <20220608061805.vvsjiqt55rqnl3fw@sirius.home.kraxel.org> References: <20220607104550.hz6c7etgxtksylwu@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 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 Wed, Jun 08, 2022 at 12:06:28AM +0000, Xu, Min M wrote: > On June 7, 2022 6:46 PM, Gerd Hoffmann wrote: > > On Mon, Jun 06, 2022 at 10:59:55AM +0800, Min Xu wrote: > > > From: Min M Xu > > > > > > 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? > It's an Open to the community that if lazy accept should be enabled in > OvmfPkgX64. I would like to hear the suggestions/comments from you > guys. So as the first step, it is disabled. I think OvmfPkgX64 and IntelTdxX64 configuration should be identical, and I'm wondering whenever this should be a compile time option in the first place. Can we simply use lazy accept unconditionally? With the edk2 memory management code being able to handle unaccepted memory I just don't see the point in supporting different options in early firmware setup. I think sec/pei should accept the memory needed to run dxe and not more. Anything beyond that can be accepted later on demand via TdxDxe. > > Also what exactly does this option mean? Is this the minimum amount of > > memory accepted by the firmware? > Yes, this option defines the minimum amount of memory accepted by the > firmware. For example, if it is 512MB, then there will be such amount > memory accepted by the firmware before jump to OS. Where does the 512MB figure come from? Using a fixed amount of memory doesn't look very robust to me. Is it possible to accept memory when the guest calls ExitBootServices? That way we could guarantee a minimum amount of *free* accepted memory being available, to make sure the linux kernel has enough memory to decompress itself, allocate memory management data structures and get its own lazy accept support going. For guests which don't support lazy accept we could offer a (runtime) option to simply accept all memory in ExitBootServices. take care, Gerd