From: "Gao, Jiaqi" <jiaqi.gao@intel.com>
To: "Yao, Jiewen" <jiewen.yao@intel.com>,
"devel@edk2.groups.io" <devel@edk2.groups.io>,
"kraxel@redhat.com" <kraxel@redhat.com>
Cc: "Wang, Jian J" <jian.j.wang@intel.com>,
"Wu, Hao A" <hao.a.wu@intel.com>,
"Bi, Dandan" <dandan.bi@intel.com>,
"gaoliming@byosoft.com.cn" <gaoliming@byosoft.com.cn>,
"Ni, Ray" <ray.ni@intel.com>,
"Kinney, Michael D" <michael.d.kinney@intel.com>,
"Zimmer, Vincent" <vincent.zimmer@intel.com>,
"Justen, Jordan L" <jordan.l.justen@intel.com>,
"Xu, Min M" <min.m.xu@intel.com>
Subject: Re: [edk2-devel] [RFC] Design review for Lazy Page Accept in TDVF
Date: Fri, 3 Sep 2021 12:34:35 +0000 [thread overview]
Message-ID: <BN9PR11MB54844A8AE18401FC8B1E8A21F2CF9@BN9PR11MB5484.namprd11.prod.outlook.com> (raw)
In-Reply-To: <PH0PR11MB4885055865FF4BA383F8D6078CCF9@PH0PR11MB4885.namprd11.prod.outlook.com>
Hi,
>
> I think we need clearly document what service can be used in
> EFI_ACCEPT_MEMORY.
> For example, can we use memory allocation service, GCD service, or MP
> service?
GCD service is provided by EFI_DXE_SERVICES, it can be used by EFI_ACCEPT_MEMORY (So updating the GCD memory map in the protocol is an option).
Memory allocation service can be used too.
We are not using MP service for now. If we need to use MP service, I think we can register a protocol notify to install EFI_ACCEPT_MEMORY when EFI_MP_SERVICE_PROTOCOL is ready.
>
> In https://github.com/mxu9/edk2/pull/9/commits, I do not find the
> producer of EFI_ACCEPT_MEMORY, would you please give me some hint?
>
EFI_ACCEPT_MEMORY is installed by TdxDxe in our POC: https://github.com/mxu9/edk2/pull/9/commits/45974892883847f9c0397ca8efcc86a0318b2c6e
> Couple of dependency issue:
> If EFI_ACCEPT_MEMORY cannot use MP service, then there might be
> performance concern.
> If it uses MP service, then we need ensure MP service is installed earlier and
> before memory accept request.
> I think we need a way to ensure there is enough memory *before* the
> protocol is installed, right?
>
Since the memory needed by protocol is the *certain* part and it will not change, I think it can be ensured.
>
> Also, would you please clarify how to fix below comment?
> //
> // Fix me! CoreAddMemorySpace() should not be called in the allocation
> process
> // because it will allocate memory for GCD map entry.
> //
>
A possible solution is to split the update of Memory Map and GCD Memory Space Map, newly accepted memory range can be added to Memory Map (through CoreAddRange(), an internal function in page management) for memory allocation firstly, then CoreAddMemorySpace() can be called safely.
This method will cause an duplicate entry in memory map. We have to do some fix in CoreAddRange() to avoid adding same range repeatedly.
Or we can use similarly way as mMapStack[] in page management for GCD map entry allocation too.
I'm not sure these are reasonable and logical solutions, so I'm trying to find another way.
Thank you,
Jiaqi
prev parent reply other threads:[~2021-09-03 12:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-30 7:49 [edk2-devel] [RFC] Design review for Lazy Page Accept in TDVF jiaqi.gao
2021-08-31 6:10 ` Gerd Hoffmann
2021-09-01 7:23 ` Gao, Jiaqi
2021-09-03 0:31 ` Yao, Jiewen
2021-09-03 5:56 ` Gerd Hoffmann
2021-09-03 12:34 ` Gao, Jiaqi
2021-09-03 12:34 ` Gao, Jiaqi [this message]
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=BN9PR11MB54844A8AE18401FC8B1E8A21F2CF9@BN9PR11MB5484.namprd11.prod.outlook.com \
--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