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.3254.1662096610815299199 for ; Thu, 01 Sep 2022 22:30:11 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bE22Lp9b; 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=1662096609; 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=BIvXFe43LCbhhVbwqMqQtafvzZ/oWnQkfMpxQ842pco=; b=bE22Lp9bQfH6pQKHrqIxf09vj01W66Pb3hiEaa+7UhNP3jo0vYg35L33vtNZhEAFdnL7RV rFMjMzy5xb0aE7tStC9DdbeSMK2VtiMu1+ncF3OTrvUHogt1yfggfEMQGuikKe6auX+9O+ zCBEuMRsOe9pCVwpAkX5FFAAJFNgCUs= 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-504-1RpSLjqpOhGqnB5-qd2chQ-1; Fri, 02 Sep 2022 01:30:07 -0400 X-MC-Unique: 1RpSLjqpOhGqnB5-qd2chQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4CA1F101A56C; Fri, 2 Sep 2022 05:30:07 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.195.70]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E83DF2166B2A; Fri, 2 Sep 2022 05:30:06 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 4ADF218003AB; Fri, 2 Sep 2022 07:30:05 +0200 (CEST) Date: Fri, 2 Sep 2022 07:30:05 +0200 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , "Aktas, Erdem" , James Bottomley , "Yao, Jiewen" , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V2 07/14] OvmfPkg: Add PCD and DEFINEs for Lazy Accept page. Message-ID: <20220902053005.q3y3a4vm4tb6yxfo@sirius.home.kraxel.org> References: <20220901155613.bor7ddpz63ps36gr@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > So the agreement in first stage is that: > 1. Accept all memory below 4G. Yes. > 2. The PcdLazyAcceptPartialMemorySize is not needed in current stage. Question is whenever we ever need PcdLazyAcceptPartialMemorySize. When accepting all memory below 4G works fast enough (which I think is the case when using 2M large pages) I don't see a reason to ever change that. > 3. The patch of "Pool and page functions accept memory when OOM > occurs" is not needed. Because OOM will not occur in the situation of > accepting all memory below 4G. Probably not in the vast majority of use cases, but there are exceptions. When unlocking luks-encrypted partitions the grub boot loader might need alot of memory for decryption (depends on encryption parameters). So being able to accept memory above 4G if needed would be good. Skipping that for the first stage and do it later is fine I think. take care, Gerd