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....@intel.com> > Sent: Wednesday, September 1, 2021 3:23 PM > To: devel@edk2.groups.io; kra...@redhat.com > Cc: Wang, Jian J <jian.j.w...@intel.com>; Wu, Hao A <hao.a...@intel.com>; > Bi, Dandan <dandan...@intel.com>; gaolim...@byosoft.com.cn; Ni, Ray > <ray...@intel.com>; Kinney, Michael D <michael.d.kin...@intel.com>; Yao, > Jiewen <jiewen....@intel.com>; Zimmer, Vincent <vincent.zim...@intel.com>; > Justen, Jordan L <jordan.l.jus...@intel.com>; Xu, Min M <min.m...@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 > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#80184): https://edk2.groups.io/g/devel/message/80184 Mute This Topic: https://groups.io/mt/85267822/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
