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.web09.2654.1662623004544113361 for ; Thu, 08 Sep 2022 00:43:24 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=YYZpuLUQ; 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=1662623003; 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=BzMxlSAn+c4RYfBIsUOIDzYA5GO727H1ct0q4a8zgbs=; b=YYZpuLUQJuwTTp0NpZVooRqkjM+Rv0JoYX7ZZoOaf/cog2ueq7fcUadqpij7Ku5L8ElWMW V3llSMQfJU1c9pg8Omh22IDcYCb6Qm1nn5iY0l1CzNnmOPUNd3Fb9Z9wAAUEV1Jsx0eY83 5Gicv6VsQfF/axD8ypbOlKDJ5dn3QBg= 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-544-b7L_9rJlPpWEQZxD1LKwiA-1; Thu, 08 Sep 2022 03:43:21 -0400 X-MC-Unique: b7L_9rJlPpWEQZxD1LKwiA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 80E67382578A; Thu, 8 Sep 2022 07:43:20 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.194.14]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 37C172026D4C; Thu, 8 Sep 2022 07:43:20 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id DF3EF18009BE; Thu, 8 Sep 2022 09:43:18 +0200 (CEST) Date: Thu, 8 Sep 2022 09:43:18 +0200 From: "Gerd Hoffmann" To: "Xu, Min M" Cc: "devel@edk2.groups.io" , "Aktas, Erdem" , James Bottomley , "Yao, Jiewen" , Tom Lendacky Subject: Re: [PATCH V3 09/12] OvmfPkg: Update ConstructFwHobList for lazy accept Message-ID: <20220908074318.737gyxd2bw2d2mya@sirius.home.kraxel.org> References: <5f53ebaa41c5231ff9bb0031ca95afd7e05684c1.1662365866.git.min.m.xu@intel.com> <20220907054149.ynwhhs3gpli5cy6l@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Sep 08, 2022 at 12:48:05AM +0000, Xu, Min M wrote: > On September 7, 2022 1:42 PM, Gerd Hoffmann wrote: > > Hi, > > > > > + // > > > + // This memory region is split into 2 parts. The left part is accepted. > > > + // > > > + PhysicalEnd = MaxAcceptedMemoryAddress; > > > + ResourceLength = PhysicalEnd - PhysicalStart; > > > > Same comment here. Can't happen when all memory below 4G is accepted, > > and I think MaxAcceptedMemoryAddress is not needed either. > It may happen. For example, a TD VM is created with 2G memory, then > the MaxAcceptedMemoryAddress is 0x80000000. If it is created with 1G > memory, MaxAcceptedMemoryAddress is 0x40000000. This information can > be retrieved by walking thru the TD-Hob and read the largest address > of the unaccept-mem-region under 4G. But I think it's easier to > record the value in MaxAcceptedMemoryAddress. And it can be used when > not all memory below 4G is accepted. Memory regions wouldn't cross the 4G border, they are either completely below 4G or completely above 4G. So when we accept all memory below 4G we will never have to split a memory region and you can easily figure whenever an region is accepted or not by checking whenever it is above or below 4G. I still don't see what MaxAcceptedMemoryAddress would be needed for given that when we never have to split memory regions. take care, Gerd