[edk2-devel] [RFC] Design review for Lazy Page Accept in TDVF

Yao, Jiewen jiewen.yao at intel.com
Fri Sep 3 00:31:57 UTC 2021


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 at intel.com>
> Sent: Wednesday, September 1, 2021 3:23 PM
> To: devel at edk2.groups.io; kraxel at redhat.com
> Cc: Wang, Jian J <jian.j.wang at intel.com>; Wu, Hao A <hao.a.wu at intel.com>;
> Bi, Dandan <dandan.bi at intel.com>; gaoliming at byosoft.com.cn; Ni, Ray
> <ray.ni at intel.com>; Kinney, Michael D <michael.d.kinney at intel.com>; Yao,
> Jiewen <jiewen.yao at intel.com>; Zimmer, Vincent <vincent.zimmer at intel.com>;
> Justen, Jordan L <jordan.l.justen at intel.com>; Xu, Min M <min.m.xu at 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/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-






More information about the edk2-devel-archive mailing list