MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 6 + MdeModulePkg/Core/Dxe/Mem/Page.c | 63 ++++++++--- MdeModulePkg/Include/Pi/PrePiDxeCis.h | 25 +++++ MdeModulePkg/Include/Pi/PrePiHob.h | 20 ++++ MdePkg/Include/Pi/PiDxeCis.h | 10 +- MdePkg/Include/Pi/PiHob.h | 11 +- MdePkg/Include/Protocol/MemoryAccept.h | 37 +++++++ MdePkg/Include/Uefi/UefiMultiPhase.h | 5 + MdePkg/MdePkg.dec | 3 + .../BaseMemEncryptTdxLib.inf | 3 + .../BaseMemEncryptTdxLib/MemoryEncryption.c | 12 +- OvmfPkg/Library/PeilessStartupLib/Hob.c | 5 +- OvmfPkg/Library/PlatformInitLib/IntelTdx.c | 98 ++++++++++++++--- OvmfPkg/Library/PlatformInitLib/MemDetect.c | 2 + OvmfPkg/TdxDxe/TdxDxe.c | 103 ++++++++++++++++++ OvmfPkg/TdxDxe/TdxDxe.inf | 2 + .../UefiShellDebug1CommandsLib/MemMap.c | 13 +++ .../UefiShellDebug1CommandsLib.uni | 3 +- 18 files changed, 381 insertions(+), 40 deletions(-) create mode 100644 MdeModulePkg/Include/Pi/PrePiDxeCis.h create mode 100644 MdeModulePkg/Include/Pi/PrePiHob.h create mode 100644 MdePkg/Include/Protocol/MemoryAccept.h
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
UnacceptedMemory is one of the four defined types of TD memory in Intel
TDX guest. TDVF must invoke TDCALL [TDG.MEM.PAGE.ACCEPT] the unaccepted
memory before use it. See [TDVF] Section 7.1.
TDVF: https://www.intel.com/content/dam/develop/external/us/en/
documents/tdx-virtual-firmware-design-guide-rev-1.01.pdf
It is a time-consuming task which impacts the boot performance badly.
One of the mitigation is the lazy-accept mechanism. That the whole system
memory is divided into 2 parts, one is accepted in bios phase, the other
is tagged as EfiGcdMemoryTypeUnaccepted and OS will handle these
"unaccepted" memories.
See "UEFI Spec v2.9 Table 7-5 Memory Type Usage before ExitBootServices()"
As the first stage we accept all the memory under 4G. Please see the
discussion in https://edk2.groups.io/g/devel/message/93086
This patch-set is related to code first, so there is a edk2-staging branch.
Please see https://github.com/tianocore/edk2-staging/tree/TDVF
Patch 1-4:
Introduce lazy-accept related definitions.
Patch 5-6:
Update Dxe and shell for unaccepted memory.
Patch 7:
Update OvmfPkg for unaccepted memory.
Patch 8 - 10:
Introduce EfiMemoryAcceptProtocol and realize it in TdxDxe.
Code: https://github.com/mxu9/edk2/tree/lazyaccept.v4
v4 changes:
- To follow the name convention of EDKII code first, the name of
EFI_RESOURCE_MEMORY_UNACCEPTED is updated to
BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED.
- Remove the definition of MaxAcceptedMemoryAddress because in current
stage we will accept all the memory under 4G. So
MaxAcceptedMemoryAddress is not useable in this assumption.
- Because this is related to code first, there is edk2-staging branch.
The branch link is attached.
https://github.com/tianocore/edk2-staging/tree/TDVF
v3 changes:
- As the first stage we accept all the memory under 4G. See the
discussion in https://edk2.groups.io/g/devel/message/93086
- "Pool and page functions accept memory when OOM occurs" is dropped.
See the discussion in https://edk2.groups.io/g/devel/message/93086
- PlatformAdjustSystemMemorySizeBelow4gbForLazyAccep is deleted
because in current stage we accept all the memory under 4G.
v2 changes:
- Fix a typo that change EfiUnacceptedMemory to EfiUnacceptedMemoryType.
- Define EFI_GCD_MEMORY_TYPE_UNACCEPTED in PrePiDxeCis.h because it has
not been defined in PI spec.
- AllocatePages should return EFI_INVALID_PARAMETERS if input MemoryType
is EfiUnacceptedMemoryType.
- Use EDKII_ prefix instead of EFI_ prefix in the protocol name of
EDKII_MEMORY_ACCEPT_PROTOCOL_GUID. Because this protocol is not EFI
defined.
- Accept memory under 4G even if the PcdLazyAcceptPartialMemorySize is
bigger than 4G. So with this setting, even if the
PcdLazyAcceptPartialMemorySize is 0 (which means to accept all
memories), only the memory under 4G will be accepted. This is to
optimize the performance.
Cc: Zhichao Gao <zhichao.gao@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Jiaqi Gao <jiaqi.gao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
Jiaqi Gao (1):
MdePkg: The prototype definition of EdkiiMemoryAcceptProtocol
Min M Xu (9):
MdeModulePkg: Add PrePiHob.h
MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE
OvmfPkg: Use BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED defined in
MdeModulePkg
MdePkg: Add UEFI Unaccepted memory definition
MdeModulePkg: Update Dxe to handle unaccepted memory type
ShellPkg: Update shell command memmap to show unaccepted memory
OvmfPkg: Introduce lazy accept in PlatformInitLib and PlatformPei
OvmfPkg: Realize EdkiiMemoryAcceptProtocol in TdxDxe
OvmfPkg: Call gEdkiiMemoryAcceptProtocolGuid to accept pages
MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 6 +
MdeModulePkg/Core/Dxe/Mem/Page.c | 63 ++++++++---
MdeModulePkg/Include/Pi/PrePiDxeCis.h | 25 +++++
MdeModulePkg/Include/Pi/PrePiHob.h | 20 ++++
MdePkg/Include/Pi/PiDxeCis.h | 10 +-
MdePkg/Include/Pi/PiHob.h | 11 +-
MdePkg/Include/Protocol/MemoryAccept.h | 37 +++++++
MdePkg/Include/Uefi/UefiMultiPhase.h | 5 +
MdePkg/MdePkg.dec | 3 +
.../BaseMemEncryptTdxLib.inf | 3 +
.../BaseMemEncryptTdxLib/MemoryEncryption.c | 12 +-
OvmfPkg/Library/PeilessStartupLib/Hob.c | 5 +-
OvmfPkg/Library/PlatformInitLib/IntelTdx.c | 98 ++++++++++++++---
OvmfPkg/Library/PlatformInitLib/MemDetect.c | 2 +
OvmfPkg/TdxDxe/TdxDxe.c | 103 ++++++++++++++++++
OvmfPkg/TdxDxe/TdxDxe.inf | 2 +
.../UefiShellDebug1CommandsLib/MemMap.c | 13 +++
.../UefiShellDebug1CommandsLib.uni | 3 +-
18 files changed, 381 insertions(+), 40 deletions(-)
create mode 100644 MdeModulePkg/Include/Pi/PrePiDxeCis.h
create mode 100644 MdeModulePkg/Include/Pi/PrePiHob.h
create mode 100644 MdePkg/Include/Protocol/MemoryAccept.h
--
2.29.2.windows.2
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#93670): https://edk2.groups.io/g/devel/message/93670
Mute This Topic: https://groups.io/mt/93645525/1787277
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org]
-=-=-=-=-=-=-=-=-=-=-=-
Hi, Liming/Jian/Zhiguang/Michael Can you help to review below patches for the lazy-accept feature? Because you're the maintainer/reviewer of the related modules. Any comment is welcome. [PATCH V4 01/10] MdeModulePkg: Add PrePiHob.h https://edk2.groups.io/g/devel/message/93671 [PATCH V4 02/10] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE https://edk2.groups.io/g/devel/message/93672 [PATCH V4 04/10] MdePkg: Add UEFI Unaccepted memory definition https://edk2.groups.io/g/devel/message/93674 [PATCH V4 05/10] MdeModulePkg: Update Dxe to handle unaccepted memory type https://edk2.groups.io/g/devel/message/93675 [PATCH V4 08/10] MdePkg: The prototype definition of EdkiiMemoryAcceptProtocol https://edk2.groups.io/g/devel/message/93678 Thanks! Min > -----Original Message----- > From: Xu, Min M <min.m.xu@intel.com> > Sent: Tuesday, September 13, 2022 8:02 AM > To: devel@edk2.groups.io > Cc: Xu, Min M <min.m.xu@intel.com>; Gao, Zhichao > <zhichao.gao@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; > Liu, Zhiguang <zhiguang.liu@intel.com>; Wang, Jian J > <jian.j.wang@intel.com>; Gao, Liming <gaoliming@byosoft.com.cn>; Ni, Ray > <ray.ni@intel.com>; Aktas, Erdem <erdemaktas@google.com>; Gerd > Hoffmann <kraxel@redhat.com>; James Bottomley <jejb@linux.ibm.com>; > Yao, Jiewen <jiewen.yao@intel.com>; Tom Lendacky > <thomas.lendacky@amd.com>; Gao, Jiaqi <jiaqi.gao@intel.com> > Subject: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest > > RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937 > > UnacceptedMemory is one of the four defined types of TD memory in Intel > TDX guest. TDVF must invoke TDCALL [TDG.MEM.PAGE.ACCEPT] the > unaccepted memory before use it. See [TDVF] Section 7.1. > TDVF: https://www.intel.com/content/dam/develop/external/us/en/ > documents/tdx-virtual-firmware-design-guide-rev-1.01.pdf > > It is a time-consuming task which impacts the boot performance badly. > One of the mitigation is the lazy-accept mechanism. That the whole system > memory is divided into 2 parts, one is accepted in bios phase, the other is > tagged as EfiGcdMemoryTypeUnaccepted and OS will handle these > "unaccepted" memories. > See "UEFI Spec v2.9 Table 7-5 Memory Type Usage before > ExitBootServices()" > > As the first stage we accept all the memory under 4G. Please see the > discussion in https://edk2.groups.io/g/devel/message/93086 > > This patch-set is related to code first, so there is a edk2-staging branch. > Please see https://github.com/tianocore/edk2-staging/tree/TDVF > > Patch 1-4: > Introduce lazy-accept related definitions. > > Patch 5-6: > Update Dxe and shell for unaccepted memory. > > Patch 7: > Update OvmfPkg for unaccepted memory. > > Patch 8 - 10: > Introduce EfiMemoryAcceptProtocol and realize it in TdxDxe. > > Code: https://github.com/mxu9/edk2/tree/lazyaccept.v4 > > v4 changes: > - To follow the name convention of EDKII code first, the name of > EFI_RESOURCE_MEMORY_UNACCEPTED is updated to > BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED. > - Remove the definition of MaxAcceptedMemoryAddress because in current > stage we will accept all the memory under 4G. So > MaxAcceptedMemoryAddress is not useable in this assumption. > - Because this is related to code first, there is edk2-staging branch. > The branch link is attached. > https://github.com/tianocore/edk2-staging/tree/TDVF > > v3 changes: > - As the first stage we accept all the memory under 4G. See the > discussion in https://edk2.groups.io/g/devel/message/93086 > - "Pool and page functions accept memory when OOM occurs" is dropped. > See the discussion in https://edk2.groups.io/g/devel/message/93086 > - PlatformAdjustSystemMemorySizeBelow4gbForLazyAccep is deleted > because in current stage we accept all the memory under 4G. > > v2 changes: > - Fix a typo that change EfiUnacceptedMemory to > EfiUnacceptedMemoryType. > - Define EFI_GCD_MEMORY_TYPE_UNACCEPTED in PrePiDxeCis.h because it > has > not been defined in PI spec. > - AllocatePages should return EFI_INVALID_PARAMETERS if input > MemoryType > is EfiUnacceptedMemoryType. > - Use EDKII_ prefix instead of EFI_ prefix in the protocol name of > EDKII_MEMORY_ACCEPT_PROTOCOL_GUID. Because this protocol is not > EFI > defined. > - Accept memory under 4G even if the PcdLazyAcceptPartialMemorySize is > bigger than 4G. So with this setting, even if the > PcdLazyAcceptPartialMemorySize is 0 (which means to accept all > memories), only the memory under 4G will be accepted. This is to > optimize the performance. > > Cc: Zhichao Gao <zhichao.gao@intel.com> > Cc: Michael D Kinney <michael.d.kinney@intel.com> > Cc: Zhiguang Liu <zhiguang.liu@intel.com> > Cc: Jian J Wang <jian.j.wang@intel.com> > Cc: Liming Gao <gaoliming@byosoft.com.cn> > Cc: Ray Ni <ray.ni@intel.com> > Cc: Erdem Aktas <erdemaktas@google.com> > Cc: Gerd Hoffmann <kraxel@redhat.com> > Cc: James Bottomley <jejb@linux.ibm.com> > Cc: Jiewen Yao <jiewen.yao@intel.com> > Cc: Tom Lendacky <thomas.lendacky@amd.com> > Signed-off-by: Jiaqi Gao <jiaqi.gao@intel.com> > Signed-off-by: Min Xu <min.m.xu@intel.com> > > Jiaqi Gao (1): > MdePkg: The prototype definition of EdkiiMemoryAcceptProtocol > > Min M Xu (9): > MdeModulePkg: Add PrePiHob.h > MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE > OvmfPkg: Use BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED defined in > MdeModulePkg > MdePkg: Add UEFI Unaccepted memory definition > MdeModulePkg: Update Dxe to handle unaccepted memory type > ShellPkg: Update shell command memmap to show unaccepted memory > OvmfPkg: Introduce lazy accept in PlatformInitLib and PlatformPei > OvmfPkg: Realize EdkiiMemoryAcceptProtocol in TdxDxe > OvmfPkg: Call gEdkiiMemoryAcceptProtocolGuid to accept pages > > MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 6 + > MdeModulePkg/Core/Dxe/Mem/Page.c | 63 ++++++++--- > MdeModulePkg/Include/Pi/PrePiDxeCis.h | 25 +++++ > MdeModulePkg/Include/Pi/PrePiHob.h | 20 ++++ > MdePkg/Include/Pi/PiDxeCis.h | 10 +- > MdePkg/Include/Pi/PiHob.h | 11 +- > MdePkg/Include/Protocol/MemoryAccept.h | 37 +++++++ > MdePkg/Include/Uefi/UefiMultiPhase.h | 5 + > MdePkg/MdePkg.dec | 3 + > .../BaseMemEncryptTdxLib.inf | 3 + > .../BaseMemEncryptTdxLib/MemoryEncryption.c | 12 +- > OvmfPkg/Library/PeilessStartupLib/Hob.c | 5 +- > OvmfPkg/Library/PlatformInitLib/IntelTdx.c | 98 ++++++++++++++--- > OvmfPkg/Library/PlatformInitLib/MemDetect.c | 2 + > OvmfPkg/TdxDxe/TdxDxe.c | 103 ++++++++++++++++++ > OvmfPkg/TdxDxe/TdxDxe.inf | 2 + > .../UefiShellDebug1CommandsLib/MemMap.c | 13 +++ > .../UefiShellDebug1CommandsLib.uni | 3 +- > 18 files changed, 381 insertions(+), 40 deletions(-) create mode 100644 > MdeModulePkg/Include/Pi/PrePiDxeCis.h > create mode 100644 MdeModulePkg/Include/Pi/PrePiHob.h > create mode 100644 MdePkg/Include/Protocol/MemoryAccept.h > > -- > 2.29.2.windows.2 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94104): https://edk2.groups.io/g/devel/message/94104 Mute This Topic: https://groups.io/mt/93645525/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On September 22, 2022 1:25 PM, Min Xu wrote: > > Hi, Liming/Jian/Zhiguang/Michael > Can you help to review below patches for the lazy-accept feature? Because > you're the maintainer/reviewer of the related modules. > Any comment is welcome. > There is still no comments received since last notification. Can Liming/Jian/Zhiguang/Michael provide your review comments about the lazy-accept feature? > > [PATCH V4 01/10] MdeModulePkg: Add PrePiHob.h > https://edk2.groups.io/g/devel/message/93671 > > [PATCH V4 02/10] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE > https://edk2.groups.io/g/devel/message/93672 > > [PATCH V4 04/10] MdePkg: Add UEFI Unaccepted memory definition > https://edk2.groups.io/g/devel/message/93674 > > [PATCH V4 05/10] MdeModulePkg: Update Dxe to handle unaccepted > memory type > https://edk2.groups.io/g/devel/message/93675 > > [PATCH V4 08/10] MdePkg: The prototype definition of > EdkiiMemoryAcceptProtocol > https://edk2.groups.io/g/devel/message/93678 > Thanks much! Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94491): https://edk2.groups.io/g/devel/message/94491 Mute This Topic: https://groups.io/mt/93645525/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Min: I have no comments for new unaccepted resource type and unaccepted gcd type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. For new protocol EfiMemoryAcceptProtocol, I see another patch serial https://edk2.groups.io/g/devel/message/94763 base on it to introduce ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two protocols be combined into one? Thanks Liming > -----邮件原件----- > 发件人: Xu, Min M <min.m.xu@intel.com> > 发送时间: 2022年9月29日 14:57 > 收件人: devel@edk2.groups.io; Gao, Liming <gaoliming@byosoft.com.cn>; > Wang, Jian J <jian.j.wang@intel.com>; Liu, Zhiguang > <zhiguang.liu@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com> > 抄送: Gao, Zhichao <zhichao.gao@intel.com>; Ni, Ray <ray.ni@intel.com>; > Aktas, Erdem <erdemaktas@google.com>; Gerd Hoffmann > <kraxel@redhat.com>; James Bottomley <jejb@linux.ibm.com>; Yao, Jiewen > <jiewen.yao@intel.com>; Tom Lendacky <thomas.lendacky@amd.com>; Gao, > Jiaqi <jiaqi.gao@intel.com> > 主题: RE: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest > > On September 22, 2022 1:25 PM, Min Xu wrote: > > > > Hi, Liming/Jian/Zhiguang/Michael > > Can you help to review below patches for the lazy-accept feature? Because > > you're the maintainer/reviewer of the related modules. > > Any comment is welcome. > > > There is still no comments received since last notification. Can > Liming/Jian/Zhiguang/Michael provide your review comments about the > lazy-accept feature? > > > > [PATCH V4 01/10] MdeModulePkg: Add PrePiHob.h > > https://edk2.groups.io/g/devel/message/93671 > > > > [PATCH V4 02/10] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE > > https://edk2.groups.io/g/devel/message/93672 > > > > [PATCH V4 04/10] MdePkg: Add UEFI Unaccepted memory definition > > https://edk2.groups.io/g/devel/message/93674 > > > > [PATCH V4 05/10] MdeModulePkg: Update Dxe to handle unaccepted > > memory type > > https://edk2.groups.io/g/devel/message/93675 > > > > [PATCH V4 08/10] MdePkg: The prototype definition of > > EdkiiMemoryAcceptProtocol > > https://edk2.groups.io/g/devel/message/93678 > > > > Thanks much! > Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94860): https://edk2.groups.io/g/devel/message/94860 Mute This Topic: https://groups.io/mt/94229046/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On October 10, 2022 10:28 AM, Gao Liming wrote: > > Min: > I have no comments for new unaccepted resource type and unaccepted gcd > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > For new protocol EfiMemoryAcceptProtocol, I see another patch serial > https://edk2.groups.io/g/devel/message/94763 base on it to introduce > ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two protocols > be combined into one? > HI, Liming There are below discussions about your comments. https://edk2.groups.io/g/devel/message/94869 https://edk2.groups.io/g/devel/message/94944 https://edk2.groups.io/g/devel/message/95050 https://edk2.groups.io/g/devel/message/95109 Do you think these discussions address your comments? Thanks Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95303): https://edk2.groups.io/g/devel/message/95303 Mute This Topic: https://groups.io/mt/94229046/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Min: I understand that they are for the different purpose and usage. But, their protocol name are very similar. If there is no better protocol name, I will also be fine. Thanks Liming > -----邮件原件----- > 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Min Xu > 发送时间: 2022年10月18日 9:13 > 收件人: devel@edk2.groups.io; Gao, Liming <gaoliming@byosoft.com.cn> > 抄送: Gao, Zhichao <zhichao.gao@intel.com>; Ni, Ray <ray.ni@intel.com>; > Aktas, Erdem <erdemaktas@google.com>; 'Gerd Hoffmann' > <kraxel@redhat.com>; 'James Bottomley' <jejb@linux.ibm.com>; Yao, Jiewen > <jiewen.yao@intel.com>; 'Tom Lendacky' <thomas.lendacky@amd.com>; > Gao, Jiaqi <jiaqi.gao@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Liu, > Zhiguang <zhiguang.liu@intel.com>; Kinney, Michael D > <michael.d.kinney@intel.com> > 主题: Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > Tdx guest > > On October 10, 2022 10:28 AM, Gao Liming wrote: > > > > Min: > > I have no comments for new unaccepted resource type and unaccepted > gcd > > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > > > For new protocol EfiMemoryAcceptProtocol, I see another patch serial > > https://edk2.groups.io/g/devel/message/94763 base on it to introduce > > ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two > protocols > > be combined into one? > > > HI, Liming > There are below discussions about your comments. > https://edk2.groups.io/g/devel/message/94869 > https://edk2.groups.io/g/devel/message/94944 > https://edk2.groups.io/g/devel/message/95050 > https://edk2.groups.io/g/devel/message/95109 > > Do you think these discussions address your comments? > > Thanks > Min > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95350): https://edk2.groups.io/g/devel/message/95350 Mute This Topic: https://groups.io/mt/94422345/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On October 19, 2022 9:18 AM, Gao Liming wrote: > > Min: > I understand that they are for the different purpose and usage. But, their > protocol name are very similar. Yes. They do look very similar. > If there is no better protocol name, I will also be fine. Dionna, what's your thought? > > On October 10, 2022 10:28 AM, Gao Liming wrote: > > > > > > Min: > > > I have no comments for new unaccepted resource type and unaccepted > > gcd > > > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > > > > > For new protocol EfiMemoryAcceptProtocol, I see another patch > > > serial > > > https://edk2.groups.io/g/devel/message/94763 base on it to introduce > > > ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two > > protocols > > > be combined into one? > > > > > HI, Liming > > There are below discussions about your comments. > > https://edk2.groups.io/g/devel/message/94869 > > https://edk2.groups.io/g/devel/message/94944 > > https://edk2.groups.io/g/devel/message/95050 > > https://edk2.groups.io/g/devel/message/95109 > > > > Do you think these discussions address your comments? > > > > Thanks > > Min > > Thanks Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95356): https://edk2.groups.io/g/devel/message/95356 Mute This Topic: https://groups.io/mt/94423128/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
> > Min: > > I understand that they are for the different purpose and usage. But, their > > protocol name are very similar. > Yes. They do look very similar. > > > If there is no better protocol name, I will also be fine. > Dionna, what's your thought? > The accept_all_unaccepted_memory name came from Ard's suggestion on an earlier patch series where I was using a Pcd. We're talking about the name over on the spec bug https://bugzilla.tianocore.org/show_bug.cgi?id=3987#c26 I think that any name concerning unaccepted memory is going to look a little same-y to others, so it's going to be troublesome if we require that they all strongly differ in name. I'm not strongly attached to the name, I just want to be conservative about what the name implies about the expected overall behavior of the system when that has not actually been decided upon. -- -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95473): https://edk2.groups.io/g/devel/message/95473 Mute This Topic: https://groups.io/mt/94423128/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Hi, Liming In Dionna's latest patch-sets the name of accept_all_unaccepted_memory has been changed to BZ3987_MEMORY_ACCEPTANCE_PROTOCOL. https://edk2.groups.io/g/devel/message/95525 https://edk2.groups.io/g/devel/message/95530 So now these 2 protocols are named as "BZ3987_MEMORY_ACCEPTANCE_PROTOCOL" and " EDKII_MEMORY_ACCEPT_PROTOCOL". Do you think they have addressed your concern? Thanks Min > -----Original Message----- > From: Dionna Amalie Glaze <dionnaglaze@google.com> > Sent: Friday, October 21, 2022 11:59 PM > To: Xu, Min M <min.m.xu@intel.com> > Cc: devel@edk2.groups.io; Gao, Liming <gaoliming@byosoft.com.cn>; Gao, > Zhichao <zhichao.gao@intel.com>; Ni, Ray <ray.ni@intel.com>; Aktas, Erdem > <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; James > Bottomley <jejb@linux.ibm.com>; Yao, Jiewen <jiewen.yao@intel.com>; Tom > Lendacky <thomas.lendacky@amd.com>; Gao, Jiaqi <jiaqi.gao@intel.com>; > Wang, Jian J <jian.j.wang@intel.com>; Liu, Zhiguang > <zhiguang.liu@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; > Ard Biesheuvel <ardb@kernel.org> > Subject: Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > Tdx guest > > > > Min: > > > I understand that they are for the different purpose and usage. > > > But, their protocol name are very similar. > > Yes. They do look very similar. > > > > > If there is no better protocol name, I will also be fine. > > Dionna, what's your thought? > > > > The accept_all_unaccepted_memory name came from Ard's suggestion on > an earlier patch series where I was using a Pcd. > We're talking about the name over on the spec bug > https://bugzilla.tianocore.org/show_bug.cgi?id=3987#c26 > > I think that any name concerning unaccepted memory is going to look a little > same-y to others, so it's going to be troublesome if we require that they all > strongly differ in name. I'm not strongly attached to the name, I just want to > be conservative about what the name implies about the expected overall > behavior of the system when that has not actually been decided upon. > > -- > -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95545): https://edk2.groups.io/g/devel/message/95545 Mute This Topic: https://groups.io/mt/94423128/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Min: Thanks for the update. I have no other comments for MdePkg changes in this patch set. Thanks Liming > -----邮件原件----- > 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Min Xu > 发送时间: 2022年10月25日 9:08 > 收件人: Dionna Amalie Glaze <dionnaglaze@google.com>; Gao, Liming > <gaoliming@byosoft.com.cn> > 抄送: devel@edk2.groups.io; Gao, Zhichao <zhichao.gao@intel.com>; Ni, Ray > <ray.ni@intel.com>; Aktas, Erdem <erdemaktas@google.com>; Gerd > Hoffmann <kraxel@redhat.com>; James Bottomley <jejb@linux.ibm.com>; > Yao, Jiewen <jiewen.yao@intel.com>; Tom Lendacky > <thomas.lendacky@amd.com>; Gao, Jiaqi <jiaqi.gao@intel.com>; Wang, Jian > J <jian.j.wang@intel.com>; Liu, Zhiguang <zhiguang.liu@intel.com>; Kinney, > Michael D <michael.d.kinney@intel.com>; Ard Biesheuvel <ardb@kernel.org>; > Xu, Min M <min.m.xu@intel.com> > 主题: Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > Tdx guest > > Hi, Liming > In Dionna's latest patch-sets the name of accept_all_unaccepted_memory > has been changed to BZ3987_MEMORY_ACCEPTANCE_PROTOCOL. > https://edk2.groups.io/g/devel/message/95525 > https://edk2.groups.io/g/devel/message/95530 > > So now these 2 protocols are named as > "BZ3987_MEMORY_ACCEPTANCE_PROTOCOL" and " > EDKII_MEMORY_ACCEPT_PROTOCOL". > Do you think they have addressed your concern? > > Thanks > Min > > > -----Original Message----- > > From: Dionna Amalie Glaze <dionnaglaze@google.com> > > Sent: Friday, October 21, 2022 11:59 PM > > To: Xu, Min M <min.m.xu@intel.com> > > Cc: devel@edk2.groups.io; Gao, Liming <gaoliming@byosoft.com.cn>; Gao, > > Zhichao <zhichao.gao@intel.com>; Ni, Ray <ray.ni@intel.com>; Aktas, > Erdem > > <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; James > > Bottomley <jejb@linux.ibm.com>; Yao, Jiewen <jiewen.yao@intel.com>; > Tom > > Lendacky <thomas.lendacky@amd.com>; Gao, Jiaqi <jiaqi.gao@intel.com>; > > Wang, Jian J <jian.j.wang@intel.com>; Liu, Zhiguang > > <zhiguang.liu@intel.com>; Kinney, Michael D > <michael.d.kinney@intel.com>; > > Ard Biesheuvel <ardb@kernel.org> > > Subject: Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept > for > > Tdx guest > > > > > > Min: > > > > I understand that they are for the different purpose and usage. > > > > But, their protocol name are very similar. > > > Yes. They do look very similar. > > > > > > > If there is no better protocol name, I will also be fine. > > > Dionna, what's your thought? > > > > > > > The accept_all_unaccepted_memory name came from Ard's suggestion on > > an earlier patch series where I was using a Pcd. > > We're talking about the name over on the spec bug > > https://bugzilla.tianocore.org/show_bug.cgi?id=3987#c26 > > > > I think that any name concerning unaccepted memory is going to look a little > > same-y to others, so it's going to be troublesome if we require that they all > > strongly differ in name. I'm not strongly attached to the name, I just want to > > be conservative about what the name implies about the expected overall > > behavior of the system when that has not actually been decided upon. > > > > -- > > -Dionna Glaze, PhD (she/her) > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95586): https://edk2.groups.io/g/devel/message/95586 Mute This Topic: https://groups.io/mt/94573125/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On October 26, 2022 9:27 AM, Gao Liming wrote: > > Min: > Thanks for the update. I have no other comments for MdePkg changes in > this patch set. > Hi, Liming Below 5 patches are changes in MdePkg and MdeModulePkg. Can you give "reviewed-by" if you have no other concerns? [PATCH V4 01/10] MdeModulePkg: Add PrePiHob.h https://edk2.groups.io/g/devel/message/93671 [PATCH V4 02/10] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE https://edk2.groups.io/g/devel/message/93672 [PATCH V4 04/10] MdePkg: Add UEFI Unaccepted memory definition https://edk2.groups.io/g/devel/message/93674 [PATCH V4 05/10] MdeModulePkg: Update Dxe to handle unaccepted memory type https://edk2.groups.io/g/devel/message/93675 [PATCH V4 08/10] MdePkg: The prototype definition of EdkiiMemoryAcceptProtocol https://edk2.groups.io/g/devel/message/93678 Thanks Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95609): https://edk2.groups.io/g/devel/message/95609 Mute This Topic: https://groups.io/mt/94581434/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
I have no more comments. Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn> for those changes. > -----邮件原件----- > 发件人: devel@edk2.groups.io <devel@edk2.groups.io> 代表 Min Xu > 发送时间: 2022年10月26日 21:35 > 收件人: devel@edk2.groups.io; Gao, Liming <gaoliming@byosoft.com.cn>; > 'Dionna Amalie Glaze' <dionnaglaze@google.com> > 抄送: Gao, Zhichao <zhichao.gao@intel.com>; Ni, Ray <ray.ni@intel.com>; > Aktas, Erdem <erdemaktas@google.com>; 'Gerd Hoffmann' > <kraxel@redhat.com>; 'James Bottomley' <jejb@linux.ibm.com>; Yao, Jiewen > <jiewen.yao@intel.com>; 'Tom Lendacky' <thomas.lendacky@amd.com>; > Gao, Jiaqi <jiaqi.gao@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Liu, > Zhiguang <zhiguang.liu@intel.com>; Kinney, Michael D > <michael.d.kinney@intel.com>; 'Ard Biesheuvel' <ardb@kernel.org> > 主题: Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > Tdx guest > > On October 26, 2022 9:27 AM, Gao Liming wrote: > > > > Min: > > Thanks for the update. I have no other comments for MdePkg changes in > > this patch set. > > > Hi, Liming > Below 5 patches are changes in MdePkg and MdeModulePkg. Can you give > "reviewed-by" if you have no other concerns? > > [PATCH V4 01/10] MdeModulePkg: Add PrePiHob.h > https://edk2.groups.io/g/devel/message/93671 > > [PATCH V4 02/10] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE > https://edk2.groups.io/g/devel/message/93672 > > [PATCH V4 04/10] MdePkg: Add UEFI Unaccepted memory definition > https://edk2.groups.io/g/devel/message/93674 > > [PATCH V4 05/10] MdeModulePkg: Update Dxe to handle unaccepted > memory type > https://edk2.groups.io/g/devel/message/93675 > > [PATCH V4 08/10] MdePkg: The prototype definition of > EdkiiMemoryAcceptProtocol > https://edk2.groups.io/g/devel/message/93678 > > Thanks > Min > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95788): https://edk2.groups.io/g/devel/message/95788 Mute This Topic: https://groups.io/mt/94700592/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
On October 10, 2022 10:28 AM, Gao Liming wrote: > > Min: > I have no comments for new unaccepted resource type and unaccepted gcd > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > For new protocol EfiMemoryAcceptProtocol, I see another patch serial > https://edk2.groups.io/g/devel/message/94763 base on it to introduce > ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two protocols > be combined into one? > EfiMemoryAcceptProtocol looks like this: typedef EFI_STATUS (EFIAPI *EDKII_ACCEPT_MEMORY)( IN EDKII_MEMORY_ACCEPT_PROTOCOL *This, IN EFI_PHYSICAL_ADDRESS StartAddress, IN UINTN Size ); This protocol is called to accept the memory based on the input start address and size. While ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL looks like below: typedef EFI_STATUS (EFIAPI *BZ3987_DISABLE_ACCEPT_ALL_UNACCEPTED_MEMORY)( IN BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL *This ); According to its description (https://edk2.groups.io/g/devel/message/94768) this protocol is used to disable the behavior of accepting all unaccepted memory. And it is designed to be called by the OS loader, not EDK2 itself. I am afraid these 2 protocols cannot be combined into one. Dionna what's your thought? Thanks Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94869): https://edk2.groups.io/g/devel/message/94869 Mute This Topic: https://groups.io/mt/94229046/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
Can OS call AcceptMemory protocol for those ranges that are not accepted? > -----Original Message----- > From: Xu, Min M <min.m.xu@intel.com> > Sent: Monday, October 10, 2022 11:08 AM > To: devel@edk2.groups.io; Dionna Amalie Glaze <dionnaglaze@google.com>; > Gao, Liming <gaoliming@byosoft.com.cn> > Cc: Gao, Zhichao <zhichao.gao@intel.com>; Ni, Ray <ray.ni@intel.com>; > Aktas, Erdem <erdemaktas@google.com>; 'Gerd Hoffmann' > <kraxel@redhat.com>; 'James Bottomley' <jejb@linux.ibm.com>; Yao, > Jiewen <jiewen.yao@intel.com>; 'Tom Lendacky' > <thomas.lendacky@amd.com>; Gao, Jiaqi <jiaqi.gao@intel.com>; Wang, Jian > J <jian.j.wang@intel.com>; Liu, Zhiguang <zhiguang.liu@intel.com>; Kinney, > Michael D <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com> > Subject: RE: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > Tdx guest > > On October 10, 2022 10:28 AM, Gao Liming wrote: > > > > Min: > > I have no comments for new unaccepted resource type and unaccepted > gcd > > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > > > For new protocol EfiMemoryAcceptProtocol, I see another patch serial > > https://edk2.groups.io/g/devel/message/94763 base on it to introduce > > ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two > protocols > > be combined into one? > > > EfiMemoryAcceptProtocol looks like this: > typedef > EFI_STATUS > (EFIAPI *EDKII_ACCEPT_MEMORY)( > IN EDKII_MEMORY_ACCEPT_PROTOCOL *This, > IN EFI_PHYSICAL_ADDRESS StartAddress, > IN UINTN Size > ); > This protocol is called to accept the memory based on the input start address > and size. > > While ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL looks like below: > typedef > EFI_STATUS > (EFIAPI *BZ3987_DISABLE_ACCEPT_ALL_UNACCEPTED_MEMORY)( > IN BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL *This > ); > According to its description (https://edk2.groups.io/g/devel/message/94768) > this protocol is used to disable the behavior of accepting all unaccepted > memory. And it is designed to be called by the OS loader, not EDK2 itself. > > I am afraid these 2 protocols cannot be combined into one. > > Dionna what's your thought? > > Thanks > Min -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94870): https://edk2.groups.io/g/devel/message/94870 Mute This Topic: https://groups.io/mt/94229046/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
> > Can OS call AcceptMemory protocol for those ranges that are not accepted? > AcceptMemory is not specified to avoid accepting previously accepted memory. As I understand it, AcceptMemory is purely a hardware abstraction layer for CC technologies inside the UEFI implementation. It additionally is not meant to modify address spaces. Address space modification happens around it. Gao has a point though, that the two could be combined. I'm not sure if it's particularly helpful to expose AcceptMemory to the OS. Exposing it I think would necessitate changing its semantics to be safer, e.g., Use the insight that AcceptMemory is only used to accept full or partial regions of unaccepted memory spaces: /** * Accepts memory in page granularity from the beginning of a pointed-to memory descriptor, and changes * the type of the affected memory range to EfiConventionalMemory. * * @param[This] This A pointer to this protocol instance * @param[AddressInSpace] An address within the memory descriptor from which to accept pages. * @param[NumPages] The amount of EFI_PAGE_SIZE blocks of memory to accept from the memory * descriptor's beginning and convert into EfiConventionalMemory. If pages remain in the memory descriptor * after acceptance, the remaining memory will start at the initial memory descriptor's * start address + NumPages * EFI_PAGE_SIZE * with type EfiUnacceptedMemory. * The changes to the memory map affect only the memory descriptor named by AddressInSpace. * * Returns EFI_INVALID_PARAMETER if AddressInSpace names to a memory descriptor that is not * EfiUnacceptedMemory, or if the named memory descriptor is not at least NumPages in size. */ EFI_STATUS EFIAPI AcceptFromMemorySpaceBeginning ( IN ProtocolType *This, IN EFI_VIRTUAL_ADDRESS AddressInSpace, IN UINTN NumPages ); /** * To be called by the OS loader to indicate that it supports and accepts responsibility for EfiUnacceptedMemory. * * Without calling this function, ExitBootServices will accept all unaccepted memory before returning. This * behavior maintains safety for OSes that do not support unaccepted memory or know of this protocol. */ VOID EFIAPI DisableAcceptAllOnExitBootServices (IN ProtocolType *This); I think this could be a fine protocol to expose to the OS loader since it would be safer written this way, albeit AcceptFromMemorySpaceBeginning is rather redundant for the behavior that the OS would need to implement if it calls the disable function. I'm not too pleased about the naming behavior, but I also don't really like requiring the interface to only accept the start address of any particular memory descriptor. That's a matter of taste though. The implementation of the memory descriptor search would not be much more complicated than a couple inequality checks instead of a single equality check. I don't think it's worth the effort in this interface to allow an arbitrary range that could split a single memory descriptor into at most three instead of at most two, since it is logic I don't think would be readily exercised. Given that we're talking about calling this function given knowledge of the MemoryMap, and that the MemoryMap should be condensed to not have separate memory descriptors that could be coalesced, I think the limitation that NumPages fits within the single descriptor is reasonable. All this being said, what's the value of combining the protocols? One fewer header and guid? I honestly don't know since I haven't been around long enough to understand how these kinds of things evolve and create possible warts. If it's just two two things though, I think a header and guid are worth avoiding confusion by exposing AcceptMemory unnecessarily. > > -----Original Message----- > > From: Xu, Min M <min.m.xu@intel.com> > > Sent: Monday, October 10, 2022 11:08 AM > > To: devel@edk2.groups.io; Dionna Amalie Glaze <dionnaglaze@google.com>; > > Gao, Liming <gaoliming@byosoft.com.cn> > > Cc: Gao, Zhichao <zhichao.gao@intel.com>; Ni, Ray <ray.ni@intel.com>; > > Aktas, Erdem <erdemaktas@google.com>; 'Gerd Hoffmann' > > <kraxel@redhat.com>; 'James Bottomley' <jejb@linux.ibm.com>; Yao, > > Jiewen <jiewen.yao@intel.com>; 'Tom Lendacky' > > <thomas.lendacky@amd.com>; Gao, Jiaqi <jiaqi.gao@intel.com>; Wang, Jian > > J <jian.j.wang@intel.com>; Liu, Zhiguang <zhiguang.liu@intel.com>; Kinney, > > Michael D <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com> > > Subject: RE: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > > Tdx guest > > > > On October 10, 2022 10:28 AM, Gao Liming wrote: > > > > > > Min: > > > I have no comments for new unaccepted resource type and unaccepted > > gcd > > > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > > > > > For new protocol EfiMemoryAcceptProtocol, I see another patch serial > > > https://edk2.groups.io/g/devel/message/94763 base on it to introduce > > > ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these two > > protocols > > > be combined into one? > > > > > EfiMemoryAcceptProtocol looks like this: > > typedef > > EFI_STATUS > > (EFIAPI *EDKII_ACCEPT_MEMORY)( > > IN EDKII_MEMORY_ACCEPT_PROTOCOL *This, > > IN EFI_PHYSICAL_ADDRESS StartAddress, > > IN UINTN Size > > ); > > This protocol is called to accept the memory based on the input start address > > and size. > > > > While ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL looks like below: > > typedef > > EFI_STATUS > > (EFIAPI *BZ3987_DISABLE_ACCEPT_ALL_UNACCEPTED_MEMORY)( > > IN BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL *This > > ); > > According to its description (https://edk2.groups.io/g/devel/message/94768) > > this protocol is used to disable the behavior of accepting all unaccepted > > memory. And it is designed to be called by the OS loader, not EDK2 itself. > > > > I am afraid these 2 protocols cannot be combined into one. > > > > Dionna what's your thought? > > > > Thanks > > Min -- -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#94944): https://edk2.groups.io/g/devel/message/94944 Mute This Topic: https://groups.io/mt/94229046/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
The name of EDKII_MEMORY_ACCEPT_PROTOCOL indicates it is only used in edk2. It's not going to be included in UEFI spec, at least in current stage. In our design of the protocol (EDKII_MEMORY_ACCEPT_PROTOCOL), it contains the function of EDKII_ACCEPT_MEMORY which is to accept the un-accepted memories based on the input address and size. We just want to make the protocol clear and straightforward. > -----Original Message----- > From: Dionna Amalie Glaze <dionnaglaze@google.com> > Sent: Monday, October 10, 2022 11:51 PM > To: Ni, Ray <ray.ni@intel.com> > Cc: Xu, Min M <min.m.xu@intel.com>; devel@edk2.groups.io; Gao, Liming > <gaoliming@byosoft.com.cn>; Gao, Zhichao <zhichao.gao@intel.com>; Aktas, > Erdem <erdemaktas@google.com>; Gerd Hoffmann <kraxel@redhat.com>; > James Bottomley <jejb@linux.ibm.com>; Yao, Jiewen > <jiewen.yao@intel.com>; Tom Lendacky <thomas.lendacky@amd.com>; Gao, > Jiaqi <jiaqi.gao@intel.com>; Wang, Jian J <jian.j.wang@intel.com>; Liu, > Zhiguang <zhiguang.liu@intel.com>; Kinney, Michael D > <michael.d.kinney@intel.com> > Subject: Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for > Tdx guest > > > > > Can OS call AcceptMemory protocol for those ranges that are not accepted? > > > > AcceptMemory is not specified to avoid accepting previously accepted > memory. As I understand it, AcceptMemory is purely a hardware abstraction > layer for CC technologies inside the UEFI implementation. > It additionally is not meant to modify address spaces. Address space > modification happens around it. Gao has a point though, that the two could > be combined. I'm not sure if it's particularly helpful to expose AcceptMemory > to the OS. Exposing it I think would necessitate changing its semantics to be > safer, e.g., > > Use the insight that AcceptMemory is only used to accept full or partial > regions of unaccepted memory spaces: > > /** > * Accepts memory in page granularity from the beginning of a pointed-to > memory descriptor, and changes > * the type of the affected memory range to EfiConventionalMemory. > * > * @param[This] This A pointer to this protocol instance > * @param[AddressInSpace] An address within the memory descriptor from > which to accept pages. > * @param[NumPages] The amount of EFI_PAGE_SIZE blocks of memory to > accept from the memory > * descriptor's beginning and convert into EfiConventionalMemory. If pages > remain in the memory descriptor > * after acceptance, the remaining memory will start at the initial memory > descriptor's > * start address + NumPages * EFI_PAGE_SIZE > * with type EfiUnacceptedMemory. > * The changes to the memory map affect only the memory descriptor > named by AddressInSpace. > * > * Returns EFI_INVALID_PARAMETER if AddressInSpace names to a memory > descriptor that is not > * EfiUnacceptedMemory, or if the named memory descriptor is not at least > NumPages in size. > */ > EFI_STATUS EFIAPI AcceptFromMemorySpaceBeginning ( > IN ProtocolType *This, > IN EFI_VIRTUAL_ADDRESS AddressInSpace, > IN UINTN NumPages > ); > > /** > * To be called by the OS loader to indicate that it supports and accepts > responsibility for EfiUnacceptedMemory. > * > * Without calling this function, ExitBootServices will accept all unaccepted > memory before returning. This > * behavior maintains safety for OSes that do not support unaccepted > memory or know of this protocol. > */ > VOID EFIAPI DisableAcceptAllOnExitBootServices (IN ProtocolType *This); > > I think this could be a fine protocol to expose to the OS loader since it would > be safer written this way, albeit AcceptFromMemorySpaceBeginning is rather > redundant for the behavior that the OS would need to implement if it calls > the disable function. > > I'm not too pleased about the naming behavior, but I also don't really like > requiring the interface to only accept the start address of any particular > memory descriptor. That's a matter of taste though. The implementation of > the memory descriptor search would not be much more complicated than a > couple inequality checks instead of a single equality check. > > I don't think it's worth the effort in this interface to allow an arbitrary range > that could split a single memory descriptor into at most three instead of at > most two, since it is logic I don't think would be readily exercised. Given that > we're talking about calling this function given knowledge of the MemoryMap, > and that the MemoryMap should be condensed to not have separate > memory descriptors that could be coalesced, I think the limitation that > NumPages fits within the single descriptor is reasonable. > > All this being said, what's the value of combining the protocols? One fewer > header and guid? I honestly don't know since I haven't been around long > enough to understand how these kinds of things evolve and create possible > warts. > > If it's just two two things though, I think a header and guid are worth > avoiding confusion by exposing AcceptMemory unnecessarily. > > > > -----Original Message----- > > > From: Xu, Min M <min.m.xu@intel.com> > > > Sent: Monday, October 10, 2022 11:08 AM > > > To: devel@edk2.groups.io; Dionna Amalie Glaze > > > <dionnaglaze@google.com>; Gao, Liming <gaoliming@byosoft.com.cn> > > > Cc: Gao, Zhichao <zhichao.gao@intel.com>; Ni, Ray > > > <ray.ni@intel.com>; Aktas, Erdem <erdemaktas@google.com>; 'Gerd > Hoffmann' > > > <kraxel@redhat.com>; 'James Bottomley' <jejb@linux.ibm.com>; Yao, > > > Jiewen <jiewen.yao@intel.com>; 'Tom Lendacky' > > > <thomas.lendacky@amd.com>; Gao, Jiaqi <jiaqi.gao@intel.com>; Wang, > > > Jian J <jian.j.wang@intel.com>; Liu, Zhiguang > > > <zhiguang.liu@intel.com>; Kinney, Michael D > > > <michael.d.kinney@intel.com>; Xu, Min M <min.m.xu@intel.com> > > > Subject: RE: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept > > > for Tdx guest > > > > > > On October 10, 2022 10:28 AM, Gao Liming wrote: > > > > > > > > Min: > > > > I have no comments for new unaccepted resource type and > > > > unaccepted > > > gcd > > > > type. In fact, they are mapping to UEFI EfiUnacceptedMemoryType. > > > > > > > > For new protocol EfiMemoryAcceptProtocol, I see another patch > > > > serial > > > > https://edk2.groups.io/g/devel/message/94763 base on it to > > > > introduce ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL. Can these > two > > > protocols > > > > be combined into one? > > > > > > > EfiMemoryAcceptProtocol looks like this: > > > typedef > > > EFI_STATUS > > > (EFIAPI *EDKII_ACCEPT_MEMORY)( > > > IN EDKII_MEMORY_ACCEPT_PROTOCOL *This, > > > IN EFI_PHYSICAL_ADDRESS StartAddress, > > > IN UINTN Size > > > ); > > > This protocol is called to accept the memory based on the input > > > start address and size. > > > > > > While ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL looks like below: > > > typedef > > > EFI_STATUS > > > (EFIAPI *BZ3987_DISABLE_ACCEPT_ALL_UNACCEPTED_MEMORY)( > > > IN BZ3987_ACCEPT_ALL_UNACCEPTED_MEMORY_PROTOCOL *This ); > > > According to its description > > > (https://edk2.groups.io/g/devel/message/94768) > > > this protocol is used to disable the behavior of accepting all > > > unaccepted memory. And it is designed to be called by the OS loader, not > EDK2 itself. > > > > > > I am afraid these 2 protocols cannot be combined into one. > > > > > > Dionna what's your thought? > > > > > > Thanks > > > Min > > > > -- > -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95050): https://edk2.groups.io/g/devel/message/95050 Mute This Topic: https://groups.io/mt/94229046/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
> The name of EDKII_MEMORY_ACCEPT_PROTOCOL indicates it is only used in edk2. Ah, yes I was basing my changes off probably a very old version of TDVF's patches that used the EFI_ naming convention, so folks looking at my branch might have been expecting that it'd be standardized. Cool. Just the one thing needed then. -- -Dionna Glaze, PhD (she/her) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#95109): https://edk2.groups.io/g/devel/message/95109 Mute This Topic: https://groups.io/mt/94229046/1787277 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [importer@patchew.org] -=-=-=-=-=-=-=-=-=-=-=-
© 2016 - 2024 Red Hat, Inc.