From: "Gerd Hoffmann" <kraxel@redhat.com>
To: "Xu, Min M" <min.m.xu@intel.com>
Cc: "devel@edk2.groups.io" <devel@edk2.groups.io>,
"Aktas, Erdem" <erdemaktas@google.com>,
James Bottomley <jejb@linux.ibm.com>,
"Yao, Jiewen" <jiewen.yao@intel.com>,
Tom Lendacky <thomas.lendacky@amd.com>
Subject: Re: [PATCH V3 09/12] OvmfPkg: Update ConstructFwHobList for lazy accept
Date: Thu, 8 Sep 2022 09:43:18 +0200 [thread overview]
Message-ID: <20220908074318.737gyxd2bw2d2mya@sirius.home.kraxel.org> (raw)
In-Reply-To: <PH0PR11MB5064618C8B856D000CB57ED5C5409@PH0PR11MB5064.namprd11.prod.outlook.com>
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
next prev parent reply other threads:[~2022-09-08 7:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-05 8:34 [PATCH V3 00/12] Introduce Lazy-accept for Tdx guest Min Xu
2022-09-05 8:34 ` [PATCH V3 01/12] MdeModulePkg: Add PrePiHob.h Min Xu
2022-09-07 5:31 ` Gerd Hoffmann
2022-09-05 8:34 ` [PATCH V3 02/12] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE Min Xu
2022-09-06 18:44 ` Michael D Kinney
2022-09-07 0:19 ` Min Xu
2022-09-05 8:34 ` [PATCH V3 03/12] OvmfPkg: Use EFI_RESOURCE_MEMORY_UNACCEPTED which defined in MdeModulePkg Min Xu
2022-09-07 5:31 ` Gerd Hoffmann
2022-09-05 8:34 ` [PATCH V3 04/12] MdePkg: Add UEFI Unaccepted memory definition Min Xu
2022-09-07 5:32 ` Gerd Hoffmann
2022-09-05 8:34 ` [PATCH V3 05/12] MdeModulePkg: Update Dxe to handle unaccepted memory type Min Xu
2022-09-07 5:32 ` Gerd Hoffmann
2022-09-05 8:35 ` [PATCH V3 06/12] ShellPkg: Update shell command memmap to show unaccepted memory Min Xu
2022-09-05 9:19 ` [edk2-devel] " Gao, Zhichao
2022-09-05 8:35 ` [PATCH V3 07/12] OvmfPkg: Add MaxAcceptedMemoryAddress in TDX work area Min Xu
2022-09-05 8:35 ` [PATCH V3 08/12] OvmfPkg: Introduce lazy accept in PlatformInitLib and PlatformPei Min Xu
2022-09-07 5:37 ` Gerd Hoffmann
2022-09-08 1:13 ` [edk2-devel] " Min Xu
2022-09-05 8:35 ` [PATCH V3 09/12] OvmfPkg: Update ConstructFwHobList for lazy accept Min Xu
2022-09-07 5:41 ` Gerd Hoffmann
2022-09-08 0:48 ` Min Xu
2022-09-08 7:43 ` Gerd Hoffmann [this message]
2022-09-05 8:35 ` [PATCH V3 10/12] MdePkg: The prototype definition of EdkiiMemoryAcceptProtocol Min Xu
2022-09-05 8:35 ` [PATCH V3 11/12] OvmfPkg: Realize EdkiiMemoryAcceptProtocol in TdxDxe Min Xu
2022-09-05 8:35 ` [PATCH V3 12/12] OvmfPkg: Call gEdkiiMemoryAcceptProtocolGuid to accept pages Min Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220908074318.737gyxd2bw2d2mya@sirius.home.kraxel.org \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox