Re: [RFC] Design review for Lazy Page Accept in TDVF


Yao, Jiewen
 

Hi
It is good idea to have a protocol to abstract TDX and SEV.

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?
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?

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?


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.
//

Thank you
Yao Jiewen

-----Original Message-----
From: Gao, Jiaqi <jiaqi.gao@intel.com>
Sent: Wednesday, September 1, 2021 3:23 PM
To: devel@edk2.groups.io; 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; Ni, Ray
<ray.ni@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; Yao,
Jiewen <jiewen.yao@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


On Tuesday, August 31, 2021 2:11 PM, Gerd Hoffmann wrote:
Motivation: Intel TDX provides memory encryption and integrity
multi-tenancy for hardware protection. A TD-guest uses TDCALL to
accept shared memory as private. However, accept whole system memory
may take a long time which will have an adverse impact on the boot
time performance.
Which order of magnitude do we talk about?
How long would it take to accept 2G of memory (all memory below 4g on
qemu q35) ?
Here is some data using different guest configurations, it will take less time with
more cpu cores.
For 2048MB memory it takes about 4 ~ 1.5 seconds using 1 ~ 4 cores guest to
accept all.
For 4096MB memory it takes about 8 ~ 3 seconds using 1 ~ 4 cores guest.

We propose three options to address this issue:
1. Modifying the memory allocation (MdeModulePkg/Core/Dxe/Mem)
logic to accept memory when OUT_OF_RESOURCE occurs.
2. Changing the process flow of QEMU direct boot and GRUB to accept
memory when loading the image fails and returns OUT_OF_RESOURCE.
3. Adding AcceptMemory() as a boot service interface to simplify the
implementation of option 2.
Underlying implementation of accepting memory is provided by a protocol
which can be installed by architecture-specific drivers such as TdxDxe.

(1) Looks best to me. From a design point of view it is a very reasonable
thing for the core memory manager to also manage the
accepted/unaccepted state of memory. It avoids duplicating the "oom -> try
AcceptMemoryRessource()" logic in bootloaders and will also cover other
oom situations.

take care,
Gerd

Join devel@edk2.groups.io to automatically receive all group messages.