* [PATCH V4 01/10] MdeModulePkg: Add PrePiHob.h
2022-09-13 0:02 [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
@ 2022-09-13 0:02 ` Min Xu
2022-09-13 0:02 ` [PATCH V4 02/10] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE Min Xu
` (9 subsequent siblings)
10 siblings, 0 replies; 29+ messages in thread
From: Min Xu @ 2022-09-13 0:02 UTC (permalink / raw)
To: devel
Cc: Min M Xu, Jian J Wang, Liming Gao, Ray Ni, Erdem Aktas,
Gerd Hoffmann, James Bottomley, Jiewen Yao, Tom Lendacky
From: Min M Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is defined for unaccepted memory.
But this defitinion has not been officially in the PI spec. Base
on the code-first we define BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED at
MdeModulePkg/Include/Pi/PrePiHob.h.
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
---
MdeModulePkg/Include/Pi/PrePiHob.h | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 MdeModulePkg/Include/Pi/PrePiHob.h
diff --git a/MdeModulePkg/Include/Pi/PrePiHob.h b/MdeModulePkg/Include/Pi/PrePiHob.h
new file mode 100644
index 000000000000..ac575e59721b
--- /dev/null
+++ b/MdeModulePkg/Include/Pi/PrePiHob.h
@@ -0,0 +1,20 @@
+/** @file
+ HOB related definitions which has not been officially published in PI.
+
+Copyright (c) 2022, Intel Corporation. All rights reserved.<BR>
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef MDE_MODULEPKG_PRE_PI_HOB_H_
+#define MDE_MODULEPKG_PRE_PI_HOB_H_
+
+//
+// BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is defined for unaccepted memory.
+// But this defitinion has not been officially in the PI spec. Base
+// on the code-first we define BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED at
+// MdeModulePkg/Include/Pi/PrePiHob.h.
+//
+#define BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED 0x00000007
+
+#endif
--
2.29.2.windows.2
^ permalink raw reply related [flat|nested] 29+ messages in thread* [PATCH V4 02/10] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE
2022-09-13 0:02 [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
2022-09-13 0:02 ` [PATCH V4 01/10] MdeModulePkg: Add PrePiHob.h Min Xu
@ 2022-09-13 0:02 ` Min Xu
2022-09-21 8:10 ` Gerd Hoffmann
2022-09-13 0:02 ` [PATCH V4 03/10] OvmfPkg: Use BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED defined in MdeModulePkg Min Xu
` (8 subsequent siblings)
10 siblings, 1 reply; 29+ messages in thread
From: Min Xu @ 2022-09-13 0:02 UTC (permalink / raw)
To: devel
Cc: Min M Xu, Michael D Kinney, Liming Gao, Zhiguang Liu, Erdem Aktas,
Gerd Hoffmann, James Bottomley, Jiewen Yao, Tom Lendacky
From: Min M Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is defined for unaccepted memory.
But this defitinion has not been officially in the PI spec. Base
on the code-first we define EFI_RESOURCE_MEMORY_UNACCEPTED at
MdeModulePkg/Include/Pi/PrePiHob.h and update EFI_RESOURCE_MAX_MEMORY_TYPE
to 8. After BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is officially published
in PI spec, we will re-visit here.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@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>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
---
MdePkg/Include/Pi/PiHob.h | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/MdePkg/Include/Pi/PiHob.h b/MdePkg/Include/Pi/PiHob.h
index e9f0ab4309d1..4605da56e247 100644
--- a/MdePkg/Include/Pi/PiHob.h
+++ b/MdePkg/Include/Pi/PiHob.h
@@ -232,7 +232,16 @@ typedef UINT32 EFI_RESOURCE_TYPE;
#define EFI_RESOURCE_MEMORY_MAPPED_IO_PORT 0x00000004
#define EFI_RESOURCE_MEMORY_RESERVED 0x00000005
#define EFI_RESOURCE_IO_RESERVED 0x00000006
-#define EFI_RESOURCE_MAX_MEMORY_TYPE 0x00000007
+//
+// BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is defined for unaccepted memory.
+// But this defitinion has not been officially in the PI spec. Base
+// on the code-first we define BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED at
+// MdeModulePkg/Include/Pi/PrePiHob.h and update EFI_RESOURCE_MAX_MEMORY_TYPE
+// to 8. After BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is officially published
+// in PI spec, we will re-visit here.
+//
+// #define BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED 0x00000007
+#define EFI_RESOURCE_MAX_MEMORY_TYPE 0x00000008
///
/// A type of recount attribute type.
--
2.29.2.windows.2
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [PATCH V4 02/10] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE
2022-09-13 0:02 ` [PATCH V4 02/10] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE Min Xu
@ 2022-09-21 8:10 ` Gerd Hoffmann
0 siblings, 0 replies; 29+ messages in thread
From: Gerd Hoffmann @ 2022-09-21 8:10 UTC (permalink / raw)
To: Min Xu
Cc: devel, Michael D Kinney, Liming Gao, Zhiguang Liu, Erdem Aktas,
James Bottomley, Jiewen Yao, Tom Lendacky
On Tue, Sep 13, 2022 at 08:02:06AM +0800, Min Xu wrote:
> From: Min M Xu <min.m.xu@intel.com>
>
> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
>
> BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is defined for unaccepted memory.
> But this defitinion has not been officially in the PI spec. Base
> on the code-first we define EFI_RESOURCE_MEMORY_UNACCEPTED at
> MdeModulePkg/Include/Pi/PrePiHob.h and update EFI_RESOURCE_MAX_MEMORY_TYPE
> to 8. After BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is officially published
> in PI spec, we will re-visit here.
>
> Cc: Michael D Kinney <michael.d.kinney@intel.com>
> Cc: Liming Gao <gaoliming@byosoft.com.cn>
> Cc: Zhiguang Liu <zhiguang.liu@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>
> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
> Signed-off-by: Min Xu <min.m.xu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH V4 03/10] OvmfPkg: Use BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED defined in MdeModulePkg
2022-09-13 0:02 [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
2022-09-13 0:02 ` [PATCH V4 01/10] MdeModulePkg: Add PrePiHob.h Min Xu
2022-09-13 0:02 ` [PATCH V4 02/10] MdePkg: Increase EFI_RESOURCE_MAX_MEMORY_TYPE Min Xu
@ 2022-09-13 0:02 ` Min Xu
2022-09-13 0:02 ` [PATCH V4 04/10] MdePkg: Add UEFI Unaccepted memory definition Min Xu
` (7 subsequent siblings)
10 siblings, 0 replies; 29+ messages in thread
From: Min Xu @ 2022-09-13 0:02 UTC (permalink / raw)
To: devel
Cc: Min M Xu, Erdem Aktas, Gerd Hoffmann, James Bottomley, Jiewen Yao,
Tom Lendacky
From: Min M Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED is defined in MdeModulePkg. The
files which use the definition are updated as well.
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
---
OvmfPkg/Library/PeilessStartupLib/Hob.c | 5 ++---
OvmfPkg/Library/PlatformInitLib/IntelTdx.c | 10 +++++-----
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/OvmfPkg/Library/PeilessStartupLib/Hob.c b/OvmfPkg/Library/PeilessStartupLib/Hob.c
index 5fc84a809025..630ce445ebec 100644
--- a/OvmfPkg/Library/PeilessStartupLib/Hob.c
+++ b/OvmfPkg/Library/PeilessStartupLib/Hob.c
@@ -20,10 +20,9 @@
#include <IndustryStandard/UefiTcgPlatform.h>
#include <Library/PlatformInitLib.h>
#include <OvmfPlatforms.h>
+#include <Pi/PrePiHob.h>
#include "PeilessStartupInternal.h"
-#define EFI_RESOURCE_MEMORY_UNACCEPTED 7
-
/**
* Construct the HobList in SEC phase.
*
@@ -92,7 +91,7 @@ ConstructFwHobList (
//
while (!END_OF_HOB_LIST (Hob)) {
if (Hob.Header->HobType == EFI_HOB_TYPE_RESOURCE_DESCRIPTOR) {
- if (Hob.ResourceDescriptor->ResourceType == EFI_RESOURCE_MEMORY_UNACCEPTED) {
+ if (Hob.ResourceDescriptor->ResourceType == BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED) {
PhysicalEnd = Hob.ResourceDescriptor->PhysicalStart + Hob.ResourceDescriptor->ResourceLength;
ResourceLength = Hob.ResourceDescriptor->ResourceLength;
diff --git a/OvmfPkg/Library/PlatformInitLib/IntelTdx.c b/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
index c6d7c8bb6e0e..797f880df035 100644
--- a/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
+++ b/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
@@ -20,11 +20,11 @@
#include <Library/PeiServicesLib.h>
#include <Library/TdxLib.h>
#include <Library/SynchronizationLib.h>
+#include <Pi/PrePiHob.h>
#include <WorkArea.h>
#include <ConfidentialComputingGuestAttr.h>
-#define ALIGNED_2MB_MASK 0x1fffff
-#define EFI_RESOURCE_MEMORY_UNACCEPTED 7
+#define ALIGNED_2MB_MASK 0x1fffff
/**
This function will be called to accept pages. Only BSP accepts pages.
@@ -211,7 +211,7 @@ ValidateHobList (
EFI_RESOURCE_MEMORY_MAPPED_IO_PORT,
EFI_RESOURCE_MEMORY_RESERVED,
EFI_RESOURCE_IO_RESERVED,
- EFI_RESOURCE_MEMORY_UNACCEPTED
+ BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED
};
if (VmmHobList == NULL) {
@@ -387,7 +387,7 @@ ProcessHobList (
if (Hob.Header->HobType == EFI_HOB_TYPE_RESOURCE_DESCRIPTOR) {
DEBUG ((DEBUG_INFO, "\nResourceType: 0x%x\n", Hob.ResourceDescriptor->ResourceType));
- if (Hob.ResourceDescriptor->ResourceType == EFI_RESOURCE_MEMORY_UNACCEPTED) {
+ if (Hob.ResourceDescriptor->ResourceType == BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED) {
DEBUG ((DEBUG_INFO, "ResourceAttribute: 0x%x\n", Hob.ResourceDescriptor->ResourceAttribute));
DEBUG ((DEBUG_INFO, "PhysicalStart: 0x%llx\n", Hob.ResourceDescriptor->PhysicalStart));
DEBUG ((DEBUG_INFO, "ResourceLength: 0x%llx\n", Hob.ResourceDescriptor->ResourceLength));
@@ -488,7 +488,7 @@ TransferTdxHobList (
ResourceType = Hob.ResourceDescriptor->ResourceType;
ResourceAttribute = Hob.ResourceDescriptor->ResourceAttribute;
- if (ResourceType == EFI_RESOURCE_MEMORY_UNACCEPTED) {
+ if (ResourceType == BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED) {
ResourceType = EFI_RESOURCE_SYSTEM_MEMORY;
ResourceAttribute |= (EFI_RESOURCE_ATTRIBUTE_PRESENT | EFI_RESOURCE_ATTRIBUTE_INITIALIZED | EFI_RESOURCE_ATTRIBUTE_TESTED);
}
--
2.29.2.windows.2
^ permalink raw reply related [flat|nested] 29+ messages in thread* [PATCH V4 04/10] MdePkg: Add UEFI Unaccepted memory definition
2022-09-13 0:02 [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
` (2 preceding siblings ...)
2022-09-13 0:02 ` [PATCH V4 03/10] OvmfPkg: Use BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED defined in MdeModulePkg Min Xu
@ 2022-09-13 0:02 ` Min Xu
2022-09-13 0:02 ` [PATCH V4 05/10] MdeModulePkg: Update Dxe to handle unaccepted memory type Min Xu
` (6 subsequent siblings)
10 siblings, 0 replies; 29+ messages in thread
From: Min Xu @ 2022-09-13 0:02 UTC (permalink / raw)
To: devel
Cc: Min M Xu, Michael D Kinney, Liming Gao, Zhiguang Liu, Erdem Aktas,
Gerd Hoffmann, James Bottomley, Jiewen Yao, Tom Lendacky
From: Min M Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
Plase refer to:
UEFI Spec v2.9 Table 7-5 Memory Type Usage before ExitBootServices()
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@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>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
---
MdeModulePkg/Include/Pi/PrePiDxeCis.h | 25 +++++++++++++++++++++++++
MdePkg/Include/Pi/PiDxeCis.h | 10 +++++++++-
MdePkg/Include/Uefi/UefiMultiPhase.h | 5 +++++
3 files changed, 39 insertions(+), 1 deletion(-)
create mode 100644 MdeModulePkg/Include/Pi/PrePiDxeCis.h
diff --git a/MdeModulePkg/Include/Pi/PrePiDxeCis.h b/MdeModulePkg/Include/Pi/PrePiDxeCis.h
new file mode 100644
index 000000000000..113ac37924cc
--- /dev/null
+++ b/MdeModulePkg/Include/Pi/PrePiDxeCis.h
@@ -0,0 +1,25 @@
+/** @file
+ Include file matches things in PI.
+
+Copyright (c) 2022, Intel Corporation. All rights reserved.<BR>
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef MDE_MODULEPKG_PRE_PI_DXE_CIS_H_
+#define MDE_MODULEPKG_PRE_PI_DXE_CIS_H_
+
+///
+/// A memory region that describes system memory that has not been accepted
+/// by a corresponding call to the underlying isolation architecture.
+///
+/// This memory region has not been defined in PI spec, so it is defined in
+/// PrePiDxeCis.h. And it is defined in the format of captial letters
+/// because only capital letters are allowed to be used for #define declarations.
+///
+/// After this memory region is defined in PI spec, it should be a value in
+/// EFI_GCD_MEMORY_TYPE in PiDxeCis.h.
+///
+#define EFI_GCD_MEMORY_TYPE_UNACCEPTED 7
+
+#endif
diff --git a/MdePkg/Include/Pi/PiDxeCis.h b/MdePkg/Include/Pi/PiDxeCis.h
index d0f2ed0e58df..27b219aa3ffa 100644
--- a/MdePkg/Include/Pi/PiDxeCis.h
+++ b/MdePkg/Include/Pi/PiDxeCis.h
@@ -56,7 +56,15 @@ typedef enum {
/// system. If all memory has the same reliability, then this bit is not used.
///
EfiGcdMemoryTypeMoreReliable,
- EfiGcdMemoryTypeMaximum
+ // ///
+ // /// A memory region that describes system memory that has not been accepted
+ // /// by a corresponding call to the underlying isolation architecture.
+ // ///
+ // /// Please be noted:
+ // /// EfiGcdMemoryTypeUnaccepted is defined in PrePiDxeCis.h because it has not been
+ // /// defined in PI spec.
+ // EfiGcdMemoryTypeUnaccepted,
+ EfiGcdMemoryTypeMaximum = 8
} EFI_GCD_MEMORY_TYPE;
///
diff --git a/MdePkg/Include/Uefi/UefiMultiPhase.h b/MdePkg/Include/Uefi/UefiMultiPhase.h
index 22bae43e36e8..7884913371a9 100644
--- a/MdePkg/Include/Uefi/UefiMultiPhase.h
+++ b/MdePkg/Include/Uefi/UefiMultiPhase.h
@@ -103,6 +103,11 @@ typedef enum {
/// however it happens to also support byte-addressable non-volatility.
///
EfiPersistentMemory,
+ ///
+ /// A memory region that describes system memory that has not been accepted
+ /// by a corresponding call to the underlying isolation architecture.
+ ///
+ EfiUnacceptedMemoryType,
EfiMaxMemoryType
} EFI_MEMORY_TYPE;
--
2.29.2.windows.2
^ permalink raw reply related [flat|nested] 29+ messages in thread* [PATCH V4 05/10] MdeModulePkg: Update Dxe to handle unaccepted memory type
2022-09-13 0:02 [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
` (3 preceding siblings ...)
2022-09-13 0:02 ` [PATCH V4 04/10] MdePkg: Add UEFI Unaccepted memory definition Min Xu
@ 2022-09-13 0:02 ` Min Xu
2022-09-13 0:02 ` [PATCH V4 06/10] ShellPkg: Update shell command memmap to show unaccepted memory Min Xu
` (5 subsequent siblings)
10 siblings, 0 replies; 29+ messages in thread
From: Min Xu @ 2022-09-13 0:02 UTC (permalink / raw)
To: devel
Cc: Min M Xu, Jian J Wang, Liming Gao, Ray Ni, Erdem Aktas,
Gerd Hoffmann, James Bottomley, Jiewen Yao, Tom Lendacky
From: Min M Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
Unaccepted memory is a kind of new memory type,
CoreInitializeGcdServices() and CoreGetMemoryMap() are updated to handle
the unaccepted memory type.
Ref: microsoft/mu_basecore@97e9c31
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
---
MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 6 +++
MdeModulePkg/Core/Dxe/Mem/Page.c | 63 +++++++++++++++++++++++---------
2 files changed, 52 insertions(+), 17 deletions(-)
diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
index 3763467bdbc0..792cd2e0af23 100644
--- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
+++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
@@ -8,6 +8,8 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
**/
+#include <Pi/PrePiDxeCis.h>
+#include <Pi/PrePiHob.h>
#include "DxeMain.h"
#include "Gcd.h"
#include "Mem/HeapGuard.h"
@@ -103,6 +105,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED CONST CHAR8 *mGcdMemoryTypeNames[] = {
"MMIO ", // EfiGcdMemoryTypeMemoryMappedIo
"PersisMem", // EfiGcdMemoryTypePersistent
"MoreRelia", // EfiGcdMemoryTypeMoreReliable
+ "Unaccepte", // EFI_GCD_MEMORY_TYPE_UNACCEPTED
"Unknown " // EfiGcdMemoryTypeMaximum
};
@@ -2600,6 +2603,9 @@ CoreInitializeGcdServices (
case EFI_RESOURCE_MEMORY_RESERVED:
GcdMemoryType = EfiGcdMemoryTypeReserved;
break;
+ case BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED:
+ GcdMemoryType = EFI_GCD_MEMORY_TYPE_UNACCEPTED;
+ break;
case EFI_RESOURCE_IO:
GcdIoType = EfiGcdIoTypeIo;
break;
diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index cc0b90ac0df5..160289c1f9ec 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -9,6 +9,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#include "DxeMain.h"
#include "Imem.h"
#include "HeapGuard.h"
+#include <Pi/PrePiDxeCis.h>
//
// Entry for tracking the memory regions for each memory type to coalesce similar memory types
@@ -61,6 +62,7 @@ EFI_MEMORY_TYPE_STATISTICS mMemoryTypeStatistics[EfiMaxMemoryType + 1] = {
{ 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiMemoryMappedIOPortSpace
{ 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, TRUE }, // EfiPalCode
{ 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE }, // EfiPersistentMemory
+ { 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, TRUE, FALSE }, // EfiUnacceptedMemoryType
{ 0, MAX_ALLOC_ADDRESS, 0, 0, EfiMaxMemoryType, FALSE, FALSE } // EfiMaxMemoryType
};
@@ -68,22 +70,23 @@ EFI_PHYSICAL_ADDRESS mDefaultMaximumAddress = MAX_ALLOC_ADDRESS;
EFI_PHYSICAL_ADDRESS mDefaultBaseAddress = MAX_ALLOC_ADDRESS;
EFI_MEMORY_TYPE_INFORMATION gMemoryTypeInformation[EfiMaxMemoryType + 1] = {
- { EfiReservedMemoryType, 0 },
- { EfiLoaderCode, 0 },
- { EfiLoaderData, 0 },
- { EfiBootServicesCode, 0 },
- { EfiBootServicesData, 0 },
- { EfiRuntimeServicesCode, 0 },
- { EfiRuntimeServicesData, 0 },
- { EfiConventionalMemory, 0 },
- { EfiUnusableMemory, 0 },
- { EfiACPIReclaimMemory, 0 },
- { EfiACPIMemoryNVS, 0 },
- { EfiMemoryMappedIO, 0 },
- { EfiMemoryMappedIOPortSpace, 0 },
- { EfiPalCode, 0 },
- { EfiPersistentMemory, 0 },
- { EfiMaxMemoryType, 0 }
+ { EfiReservedMemoryType, 0 },
+ { EfiLoaderCode, 0 },
+ { EfiLoaderData, 0 },
+ { EfiBootServicesCode, 0 },
+ { EfiBootServicesData, 0 },
+ { EfiRuntimeServicesCode, 0 },
+ { EfiRuntimeServicesData, 0 },
+ { EfiConventionalMemory, 0 },
+ { EfiUnusableMemory, 0 },
+ { EfiACPIReclaimMemory, 0 },
+ { EfiACPIMemoryNVS, 0 },
+ { EfiMemoryMappedIO, 0 },
+ { EfiMemoryMappedIOPortSpace, 0 },
+ { EfiPalCode, 0 },
+ { EfiPersistentMemory, 0 },
+ { EFI_GCD_MEMORY_TYPE_UNACCEPTED, 0 },
+ { EfiMaxMemoryType, 0 }
};
//
// Only used when load module at fixed address feature is enabled. True means the memory is alreay successfully allocated
@@ -1286,7 +1289,7 @@ CoreInternalAllocatePages (
}
if (((MemoryType >= EfiMaxMemoryType) && (MemoryType < MEMORY_TYPE_OEM_RESERVED_MIN)) ||
- (MemoryType == EfiConventionalMemory) || (MemoryType == EfiPersistentMemory))
+ (MemoryType == EfiConventionalMemory) || (MemoryType == EfiPersistentMemory) || (MemoryType == EfiUnacceptedMemoryType))
{
return EFI_INVALID_PARAMETER;
}
@@ -1961,6 +1964,32 @@ CoreGetMemoryMap (
MemoryMap = MergeMemoryMapDescriptor (MemoryMapStart, MemoryMap, Size);
}
+ if (MergeGcdMapEntry.GcdMemoryType == EFI_GCD_MEMORY_TYPE_UNACCEPTED) {
+ //
+ // Page Align GCD range is required. When it is converted to EFI_MEMORY_DESCRIPTOR,
+ // it will be recorded as page PhysicalStart and NumberOfPages.
+ //
+ ASSERT ((MergeGcdMapEntry.BaseAddress & EFI_PAGE_MASK) == 0);
+ ASSERT (((MergeGcdMapEntry.EndAddress - MergeGcdMapEntry.BaseAddress + 1) & EFI_PAGE_MASK) == 0);
+
+ //
+ // Create EFI_MEMORY_DESCRIPTOR for every Unaccepted GCD entries
+ //
+ MemoryMap->PhysicalStart = MergeGcdMapEntry.BaseAddress;
+ MemoryMap->VirtualStart = 0;
+ MemoryMap->NumberOfPages = RShiftU64 ((MergeGcdMapEntry.EndAddress - MergeGcdMapEntry.BaseAddress + 1), EFI_PAGE_SHIFT);
+ MemoryMap->Attribute = MergeGcdMapEntry.Attributes |
+ (MergeGcdMapEntry.Capabilities & (EFI_MEMORY_RP | EFI_MEMORY_WP | EFI_MEMORY_XP | EFI_MEMORY_RO |
+ EFI_MEMORY_UC | EFI_MEMORY_UCE | EFI_MEMORY_WC | EFI_MEMORY_WT | EFI_MEMORY_WB));
+ MemoryMap->Type = EfiUnacceptedMemoryType;
+
+ //
+ // Check to see if the new Memory Map Descriptor can be merged with an
+ // existing descriptor if they are adjacent and have the same attributes
+ //
+ MemoryMap = MergeMemoryMapDescriptor (MemoryMapStart, MemoryMap, Size);
+ }
+
if (Link == &mGcdMemorySpaceMap) {
//
// break loop when arrive at head.
--
2.29.2.windows.2
^ permalink raw reply related [flat|nested] 29+ messages in thread* [PATCH V4 06/10] ShellPkg: Update shell command memmap to show unaccepted memory
2022-09-13 0:02 [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
` (4 preceding siblings ...)
2022-09-13 0:02 ` [PATCH V4 05/10] MdeModulePkg: Update Dxe to handle unaccepted memory type Min Xu
@ 2022-09-13 0:02 ` Min Xu
2022-09-13 0:02 ` [PATCH V4 07/10] OvmfPkg: Introduce lazy accept in PlatformInitLib and PlatformPei Min Xu
` (4 subsequent siblings)
10 siblings, 0 replies; 29+ messages in thread
From: Min Xu @ 2022-09-13 0:02 UTC (permalink / raw)
To: devel
Cc: Min M Xu, Ray Ni, Zhichao Gao, Erdem Aktas, Gerd Hoffmann,
James Bottomley, Jiewen Yao, Tom Lendacky
From: Min M Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
ShellCommandRunMemMap() is updated to handle the case of unaccepted
memory type.
Cc: Ray Ni <ray.ni@intel.com>
Cc: Zhichao Gao <zhichao.gao@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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Zhichao Gao <zhichao.gao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
---
.../Library/UefiShellDebug1CommandsLib/MemMap.c | 13 +++++++++++++
.../UefiShellDebug1CommandsLib.uni | 3 ++-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/MemMap.c b/ShellPkg/Library/UefiShellDebug1CommandsLib/MemMap.c
index 72f3c58b0970..a089953b286f 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/MemMap.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/MemMap.c
@@ -26,6 +26,7 @@ STATIC CONST CHAR16 NameEfiACPIMemoryNVS[] = L"ACPIMemoryNVS";
STATIC CONST CHAR16 NameEfiMemoryMappedIO[] = L"MemoryMappedIO";
STATIC CONST CHAR16 NameEfiMemoryMappedIOPortSpace[] = L"MemoryMappedIOPortSpace";
STATIC CONST CHAR16 NameEfiPalCode[] = L"PalCode";
+STATIC CONST CHAR16 NameEfiUnacceptedMemoryType[] = L"Unaccepted";
//
// Need short names for some memory types
@@ -151,6 +152,8 @@ ShellCommandRunMemMap (
UINT64 UnusableMemoryPagesSize;
UINT64 PalCodePages;
UINT64 PalCodePagesSize;
+ UINT64 UnacceptedPages;
+ UINT64 UnacceptedPagesSize;
UINT64 PersistentPages;
UINT64 PersistentPagesSize;
BOOLEAN Sfo;
@@ -175,6 +178,7 @@ ShellCommandRunMemMap (
PalCodePages = 0;
PersistentPages = 0;
Size = 0;
+ UnacceptedPages = 0;
Descriptors = NULL;
ShellStatus = SHELL_SUCCESS;
Status = EFI_SUCCESS;
@@ -303,6 +307,11 @@ ShellCommandRunMemMap (
TotalPages += Walker->NumberOfPages;
PalCodePages += Walker->NumberOfPages;
break;
+ case EfiUnacceptedMemoryType:
+ ShellPrintHiiEx (-1, -1, NULL, (EFI_STRING_ID)(!Sfo ? STRING_TOKEN (STR_MEMMAP_LIST_ITEM) : STRING_TOKEN (STR_MEMMAP_LIST_ITEM_SFO)), gShellDebug1HiiHandle, NameEfiUnacceptedMemoryType, Walker->PhysicalStart, Walker->PhysicalStart+MultU64x64 (SIZE_4KB, Walker->NumberOfPages)-1, Walker->NumberOfPages, Walker->Attribute);
+ TotalPages += Walker->NumberOfPages;
+ UnacceptedPages += Walker->NumberOfPages;
+ break;
default:
//
// Shell Spec defines the SFO format.
@@ -335,6 +344,7 @@ ShellCommandRunMemMap (
MmioSpacePagesSize = MultU64x64 (SIZE_4KB, MmioSpacePages);
MmioPortPagesSize = MultU64x64 (SIZE_4KB, MmioPortPages);
PalCodePagesSize = MultU64x64 (SIZE_4KB, PalCodePages);
+ UnacceptedPagesSize = MultU64x64 (SIZE_4KB, UnacceptedPages);
PersistentPagesSize = MultU64x64 (SIZE_4KB, PersistentPages);
UnusableMemoryPagesSize = MultU64x64 (SIZE_4KB, UnusableMemoryPages);
if (!Sfo) {
@@ -368,6 +378,8 @@ ShellCommandRunMemMap (
MmioPortPagesSize,
PalCodePages,
PalCodePagesSize,
+ UnacceptedPages,
+ UnacceptedPagesSize,
AvailPages,
AvailPagesSize,
PersistentPages,
@@ -422,6 +434,7 @@ ShellCommandRunMemMap (
AcpiReclaimPagesSize,
AcpiNvsPagesSize,
PalCodePagesSize,
+ UnacceptedPagesSize,
PersistentPagesSize
);
}
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni
index 6693be26e699..b1d239ed37ea 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.uni
@@ -88,13 +88,14 @@
" MMIO : %,14ld Pages (%,ld Bytes)\r\n"
" MMIO_Port : %,14ld Pages (%,ld Bytes)\r\n"
" PalCode : %,14ld Pages (%,ld Bytes)\r\n"
+ " Unaccepted: %,14ld Pages (%,ld Bytes)\r\n"
" Available : %,14ld Pages (%,ld Bytes)\r\n"
" Persistent: %,14ld Pages (%,ld Bytes)\r\n"
#string STR_MEMMAP_LIST_SUMM_OTHER #language en-US " %08x : %,14ld Pages (%,ld Bytes)\r\n"
#string STR_MEMMAP_LIST_SUMM2 #language en-US " -------------- \r\n"
"Total Memory: %,14ld MB (%,ld Bytes)\r\n"
#string STR_MEMMAP_LIST_ITEM_SFO #language en-US "MemoryMap,"%s","%LX","%LX","%LX","%LX"\r\n"
-#string STR_MEMMAP_LIST_SUMM_SFO #language en-US "MemoryMapSummary,"%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld"\r\n"
+#string STR_MEMMAP_LIST_SUMM_SFO #language en-US "MemoryMapSummary,"%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld","%Ld", "%Ld"\r\n"
#string STR_EFI_COMPRESS_FAIL #language en-US "Unable to compress: %r.\r\n"
#string STR_EFI_DECOMPRESS_FAIL #language en-US "Unable to decompress: %r.\r\n"
--
2.29.2.windows.2
^ permalink raw reply related [flat|nested] 29+ messages in thread* [PATCH V4 07/10] OvmfPkg: Introduce lazy accept in PlatformInitLib and PlatformPei
2022-09-13 0:02 [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
` (5 preceding siblings ...)
2022-09-13 0:02 ` [PATCH V4 06/10] ShellPkg: Update shell command memmap to show unaccepted memory Min Xu
@ 2022-09-13 0:02 ` Min Xu
2022-09-21 8:11 ` Gerd Hoffmann
2022-09-13 0:02 ` [PATCH V4 08/10] MdePkg: The prototype definition of EdkiiMemoryAcceptProtocol Min Xu
` (3 subsequent siblings)
10 siblings, 1 reply; 29+ messages in thread
From: Min Xu @ 2022-09-13 0:02 UTC (permalink / raw)
To: devel
Cc: Min M Xu, Erdem Aktas, Gerd Hoffmann, James Bottomley, Jiewen Yao,
Tom Lendacky
From: Min M Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
There are below major changes in PlatformInitLib/PlatformPei
1. ProcessHobList
The unaccepted memory is accepted if it is under 4G address.
Please be noted: in current stage, we only accept the memory under 4G.
We will re-visit here in the future when on-demand accept memory is
required.
2. TransferTdxHobList
Transfer the unaccepted memory hob to EFI_RESOURCE_SYSTEM_MEMORY hob
if it is accepted.
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: Min Xu <min.m.xu@intel.com>
---
OvmfPkg/Library/PlatformInitLib/IntelTdx.c | 88 ++++++++++++++++++---
OvmfPkg/Library/PlatformInitLib/MemDetect.c | 2 +
2 files changed, 81 insertions(+), 9 deletions(-)
diff --git a/OvmfPkg/Library/PlatformInitLib/IntelTdx.c b/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
index 797f880df035..acd114e38e46 100644
--- a/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
+++ b/OvmfPkg/Library/PlatformInitLib/IntelTdx.c
@@ -7,6 +7,7 @@
**/
+#include <Base.h>
#include <PiPei.h>
#include <Library/BaseLib.h>
#include <Library/DebugLib.h>
@@ -25,6 +26,7 @@
#include <ConfidentialComputingGuestAttr.h>
#define ALIGNED_2MB_MASK 0x1fffff
+#define MEGABYTE_SHIFT 20
/**
This function will be called to accept pages. Only BSP accepts pages.
@@ -375,11 +377,15 @@ ProcessHobList (
EFI_STATUS Status;
EFI_PEI_HOB_POINTERS Hob;
EFI_PHYSICAL_ADDRESS PhysicalEnd;
+ UINT64 ResourceLength;
+ UINT64 AccumulateAcceptedMemory;
Status = EFI_SUCCESS;
ASSERT (VmmHobList != NULL);
Hob.Raw = (UINT8 *)VmmHobList;
+ AccumulateAcceptedMemory = 0;
+
//
// Parse the HOB list until end of list or matching type is found.
//
@@ -393,7 +399,15 @@ ProcessHobList (
DEBUG ((DEBUG_INFO, "ResourceLength: 0x%llx\n", Hob.ResourceDescriptor->ResourceLength));
DEBUG ((DEBUG_INFO, "Owner: %g\n\n", &Hob.ResourceDescriptor->Owner));
- PhysicalEnd = Hob.ResourceDescriptor->PhysicalStart + Hob.ResourceDescriptor->ResourceLength;
+ PhysicalEnd = Hob.ResourceDescriptor->PhysicalStart + Hob.ResourceDescriptor->ResourceLength;
+ ResourceLength = Hob.ResourceDescriptor->ResourceLength;
+
+ if (Hob.ResourceDescriptor->PhysicalStart >= BASE_4GB) {
+ //
+ // In current stage, we only accept the memory under 4G
+ //
+ break;
+ }
Status = BspAcceptMemoryResourceRange (
Hob.ResourceDescriptor->PhysicalStart,
@@ -402,6 +416,8 @@ ProcessHobList (
if (EFI_ERROR (Status)) {
break;
}
+
+ AccumulateAcceptedMemory += ResourceLength;
}
}
@@ -460,6 +476,60 @@ ProcessTdxHobList (
return Status;
}
+/**
+ * Build ResourceDescriptorHob for the unaccepted memory region.
+ * This memory region may be splitted into 2 parts because of lazy accept.
+ *
+ * @param Hob Point to the EFI_HOB_RESOURCE_DESCRIPTOR
+ * @return VOID
+ */
+VOID
+BuildResourceDescriptorHobForUnacceptedMemory (
+ IN EFI_HOB_RESOURCE_DESCRIPTOR *Hob
+ )
+{
+ EFI_PHYSICAL_ADDRESS PhysicalStart;
+ EFI_PHYSICAL_ADDRESS PhysicalEnd;
+ UINT64 ResourceLength;
+ EFI_RESOURCE_TYPE ResourceType;
+ EFI_RESOURCE_ATTRIBUTE_TYPE ResourceAttribute;
+ UINT64 MaxAcceptedMemoryAddress;
+
+ ASSERT (Hob->ResourceType == BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED);
+
+ ResourceType = BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED;
+ ResourceAttribute = Hob->ResourceAttribute;
+ PhysicalStart = Hob->PhysicalStart;
+ ResourceLength = Hob->ResourceLength;
+ PhysicalEnd = PhysicalStart + ResourceLength;
+
+ //
+ // In the first stage of lazy-accept, all the memory under 4G will be accepted.
+ // The memory above 4G will not be accepted.
+ //
+ MaxAcceptedMemoryAddress = BASE_4GB;
+
+ if (PhysicalEnd <= MaxAcceptedMemoryAddress) {
+ //
+ // This memory region has been accepted.
+ //
+ ResourceType = EFI_RESOURCE_SYSTEM_MEMORY;
+ ResourceAttribute |= (EFI_RESOURCE_ATTRIBUTE_PRESENT | EFI_RESOURCE_ATTRIBUTE_INITIALIZED | EFI_RESOURCE_ATTRIBUTE_TESTED);
+ } else if (PhysicalStart >= MaxAcceptedMemoryAddress) {
+ //
+ // This memory region hasn't been accepted.
+ // So keep the ResourceType and ResourceAttribute unchange.
+ //
+ }
+
+ BuildResourceDescriptorHob (
+ ResourceType,
+ ResourceAttribute,
+ PhysicalStart,
+ ResourceLength
+ );
+}
+
/**
Transfer the incoming HobList for the TD to the final HobList for Dxe.
The Hobs transferred in this function are ResourceDescriptor hob and
@@ -489,16 +559,16 @@ TransferTdxHobList (
ResourceAttribute = Hob.ResourceDescriptor->ResourceAttribute;
if (ResourceType == BZ3937_EFI_RESOURCE_MEMORY_UNACCEPTED) {
- ResourceType = EFI_RESOURCE_SYSTEM_MEMORY;
- ResourceAttribute |= (EFI_RESOURCE_ATTRIBUTE_PRESENT | EFI_RESOURCE_ATTRIBUTE_INITIALIZED | EFI_RESOURCE_ATTRIBUTE_TESTED);
+ BuildResourceDescriptorHobForUnacceptedMemory (Hob.ResourceDescriptor);
+ } else {
+ BuildResourceDescriptorHob (
+ ResourceType,
+ ResourceAttribute,
+ Hob.ResourceDescriptor->PhysicalStart,
+ Hob.ResourceDescriptor->ResourceLength
+ );
}
- BuildResourceDescriptorHob (
- ResourceType,
- ResourceAttribute,
- Hob.ResourceDescriptor->PhysicalStart,
- Hob.ResourceDescriptor->ResourceLength
- );
break;
case EFI_HOB_TYPE_MEMORY_ALLOCATION:
BuildMemoryAllocationHob (
diff --git a/OvmfPkg/Library/PlatformInitLib/MemDetect.c b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
index 942eaf89cfcf..62132f9cacfa 100644
--- a/OvmfPkg/Library/PlatformInitLib/MemDetect.c
+++ b/OvmfPkg/Library/PlatformInitLib/MemDetect.c
@@ -42,6 +42,8 @@ Module Name:
#include <Library/PlatformInitLib.h>
+#define MEGABYTE_SHIFT 20
+
VOID
EFIAPI
PlatformQemuUc32BaseInitialization (
--
2.29.2.windows.2
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [PATCH V4 07/10] OvmfPkg: Introduce lazy accept in PlatformInitLib and PlatformPei
2022-09-13 0:02 ` [PATCH V4 07/10] OvmfPkg: Introduce lazy accept in PlatformInitLib and PlatformPei Min Xu
@ 2022-09-21 8:11 ` Gerd Hoffmann
0 siblings, 0 replies; 29+ messages in thread
From: Gerd Hoffmann @ 2022-09-21 8:11 UTC (permalink / raw)
To: Min Xu; +Cc: devel, Erdem Aktas, James Bottomley, Jiewen Yao, Tom Lendacky
On Tue, Sep 13, 2022 at 08:02:11AM +0800, Min Xu wrote:
> From: Min M Xu <min.m.xu@intel.com>
>
> RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
>
> There are below major changes in PlatformInitLib/PlatformPei
> 1. ProcessHobList
> The unaccepted memory is accepted if it is under 4G address.
> Please be noted: in current stage, we only accept the memory under 4G.
> We will re-visit here in the future when on-demand accept memory is
> required.
>
> 2. TransferTdxHobList
> Transfer the unaccepted memory hob to EFI_RESOURCE_SYSTEM_MEMORY hob
> if it is accepted.
>
> 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: Min Xu <min.m.xu@intel.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH V4 08/10] MdePkg: The prototype definition of EdkiiMemoryAcceptProtocol
2022-09-13 0:02 [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
` (6 preceding siblings ...)
2022-09-13 0:02 ` [PATCH V4 07/10] OvmfPkg: Introduce lazy accept in PlatformInitLib and PlatformPei Min Xu
@ 2022-09-13 0:02 ` Min Xu
2022-09-13 0:02 ` [PATCH V4 09/10] OvmfPkg: Realize EdkiiMemoryAcceptProtocol in TdxDxe Min Xu
` (2 subsequent siblings)
10 siblings, 0 replies; 29+ messages in thread
From: Min Xu @ 2022-09-13 0:02 UTC (permalink / raw)
To: devel
Cc: Jiaqi Gao, Michael D Kinney, Liming Gao, Zhiguang Liu,
Erdem Aktas, Gerd Hoffmann, James Bottomley, Jiewen Yao,
Tom Lendacky, Min Xu
From: Jiaqi Gao <jiaqi.gao@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
EdkiiMemoryAcceptProtocol is defined in MdePkg, the method AcceptMemory()
can be called when memory needs to be accepted.
EdkiiMemoryAcceptProtocol can be installed by architecture-specific
drivers such as TdxDxe. This allows different isolation architectures
to realize their own low-level methods to accept memory.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Jiaqi Gao <jiaqi.gao@intel.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
---
MdePkg/Include/Protocol/MemoryAccept.h | 37 ++++++++++++++++++++++++++
MdePkg/MdePkg.dec | 3 +++
2 files changed, 40 insertions(+)
create mode 100644 MdePkg/Include/Protocol/MemoryAccept.h
diff --git a/MdePkg/Include/Protocol/MemoryAccept.h b/MdePkg/Include/Protocol/MemoryAccept.h
new file mode 100644
index 000000000000..f7646e04d8a1
--- /dev/null
+++ b/MdePkg/Include/Protocol/MemoryAccept.h
@@ -0,0 +1,37 @@
+/** @file
+ The file provides the protocol to provide interface to accept memory.
+
+ Copyright (c) 2021 - 2022, Intel Corporation. All rights reserved.<BR>
+ SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#ifndef MEMORY_ACCEPT_H_
+#define MEMORY_ACCEPT_H_
+
+#define EDKII_MEMORY_ACCEPT_PROTOCOL_GUID \
+ { 0x38c74800, 0x5590, 0x4db4, { 0xa0, 0xf3, 0x67, 0x5d, 0x9b, 0x8e, 0x80, 0x26 } };
+
+typedef struct _EDKII_MEMORY_ACCEPT_PROTOCOL EDKII_MEMORY_ACCEPT_PROTOCOL;
+
+/**
+ @param This A pointer to a EDKII_MEMORY_ACCEPT_PROTOCOL.
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EDKII_ACCEPT_MEMORY)(
+ IN EDKII_MEMORY_ACCEPT_PROTOCOL *This,
+ IN EFI_PHYSICAL_ADDRESS StartAddress,
+ IN UINTN Size
+ );
+
+///
+/// The EDKII_MEMORY_ACCEPT_PROTOCOL provides the ability for memory services
+/// to accept memory.
+///
+struct _EDKII_MEMORY_ACCEPT_PROTOCOL {
+ EDKII_ACCEPT_MEMORY AcceptMemory;
+};
+
+extern EFI_GUID gEdkiiMemoryAcceptProtocolGuid;
+
+#endif
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index f1ebf9e251c1..6b6bfbec29b3 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -1019,6 +1019,9 @@
gEfiPeiDelayedDispatchPpiGuid = { 0x869c711d, 0x649c, 0x44fe, { 0x8b, 0x9e, 0x2c, 0xbb, 0x29, 0x11, 0xc3, 0xe6 }}
[Protocols]
+ ## Include/Protocol/MemoryAccept.h
+ gEdkiiMemoryAcceptProtocolGuid = { 0x38c74800, 0x5590, 0x4db4, { 0xa0, 0xf3, 0x67, 0x5d, 0x9b, 0x8e, 0x80, 0x26 }}
+
## Include/Protocol/Pcd.h
gPcdProtocolGuid = { 0x11B34006, 0xD85B, 0x4D0A, { 0xA2, 0x90, 0xD5, 0xA5, 0x71, 0x31, 0x0E, 0xF7 }}
--
2.29.2.windows.2
^ permalink raw reply related [flat|nested] 29+ messages in thread* [PATCH V4 09/10] OvmfPkg: Realize EdkiiMemoryAcceptProtocol in TdxDxe
2022-09-13 0:02 [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
` (7 preceding siblings ...)
2022-09-13 0:02 ` [PATCH V4 08/10] MdePkg: The prototype definition of EdkiiMemoryAcceptProtocol Min Xu
@ 2022-09-13 0:02 ` Min Xu
2022-09-13 0:02 ` [PATCH V4 10/10] OvmfPkg: Call gEdkiiMemoryAcceptProtocolGuid to accept pages Min Xu
2022-09-22 5:25 ` [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
10 siblings, 0 replies; 29+ messages in thread
From: Min Xu @ 2022-09-13 0:02 UTC (permalink / raw)
To: devel
Cc: Min M Xu, Erdem Aktas, Gerd Hoffmann, James Bottomley, Jiewen Yao,
Tom Lendacky
From: Min M Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
Memory usage may exceed the amount accepted at the begining (SEC), TDVF
needs to accept memory dynamically when OUT_OF_RESOURCE occurs.
Another usage is in SetOrClearSharedBit. If a memory region is changed from
shared to private, it must be accepted again.
EdkiiMemoryAcceptProtocol is defined in MdePkg and is implementated /
installed in TdxDxe for Intel TDX memory acceptance.
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>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
---
OvmfPkg/TdxDxe/TdxDxe.c | 103 ++++++++++++++++++++++++++++++++++++++
OvmfPkg/TdxDxe/TdxDxe.inf | 2 +
2 files changed, 105 insertions(+)
diff --git a/OvmfPkg/TdxDxe/TdxDxe.c b/OvmfPkg/TdxDxe/TdxDxe.c
index 05cfb597dc64..30732f421bb6 100644
--- a/OvmfPkg/TdxDxe/TdxDxe.c
+++ b/OvmfPkg/TdxDxe/TdxDxe.c
@@ -24,6 +24,7 @@
#include <Library/HobLib.h>
#include <Protocol/Cpu.h>
#include <Protocol/MpInitLibDepProtocols.h>
+#include <Protocol/MemoryAccept.h>
#include <Library/UefiBootServicesTableLib.h>
#include <ConfidentialComputingGuestAttr.h>
#include <IndustryStandard/Tdx.h>
@@ -32,6 +33,95 @@
#include <TdxAcpiTable.h>
#include <Library/MemEncryptTdxLib.h>
+#define ALIGNED_2MB_MASK 0x1fffff
+EFI_HANDLE mTdxDxeHandle = NULL;
+
+EFI_STATUS
+EFIAPI
+TdxMemoryAccept (
+ IN EDKII_MEMORY_ACCEPT_PROTOCOL *This,
+ IN EFI_PHYSICAL_ADDRESS StartAddress,
+ IN UINTN Size
+ )
+{
+ EFI_STATUS Status;
+ UINT32 AcceptPageSize;
+ UINT64 StartAddress1;
+ UINT64 StartAddress2;
+ UINT64 StartAddress3;
+ UINT64 Length1;
+ UINT64 Length2;
+ UINT64 Length3;
+ UINT64 Pages;
+
+ AcceptPageSize = FixedPcdGet32 (PcdTdxAcceptPageSize);
+ StartAddress1 = 0;
+ StartAddress2 = 0;
+ StartAddress3 = 0;
+ Length1 = 0;
+ Length2 = 0;
+ Length3 = 0;
+
+ if (Size == 0) {
+ return EFI_SUCCESS;
+ }
+
+ if (ALIGN_VALUE (StartAddress, SIZE_2MB) != StartAddress) {
+ StartAddress1 = StartAddress;
+ Length1 = ALIGN_VALUE (StartAddress, SIZE_2MB) - StartAddress;
+ if (Length1 >= Size) {
+ Length1 = Size;
+ }
+
+ StartAddress += Length1;
+ Size -= Length1;
+ }
+
+ if (Size > SIZE_2MB) {
+ StartAddress2 = StartAddress;
+ Length2 = Size & ~(UINT64)ALIGNED_2MB_MASK;
+ StartAddress += Length2;
+ Size -= Length2;
+ }
+
+ if (Size) {
+ StartAddress3 = StartAddress;
+ Length3 = Size;
+ }
+
+ Status = EFI_SUCCESS;
+ if (Length1 > 0) {
+ Pages = Length1 / SIZE_4KB;
+ Status = TdAcceptPages (StartAddress1, Pages, SIZE_4KB);
+ if (EFI_ERROR (Status)) {
+ return Status;
+ }
+ }
+
+ if (Length2 > 0) {
+ Pages = Length2 / AcceptPageSize;
+ Status = TdAcceptPages (StartAddress2, Pages, AcceptPageSize);
+ if (EFI_ERROR (Status)) {
+ return Status;
+ }
+ }
+
+ if (Length3 > 0) {
+ Pages = Length3 / SIZE_4KB;
+ Status = TdAcceptPages (StartAddress3, Pages, SIZE_4KB);
+ ASSERT (!EFI_ERROR (Status));
+ if (EFI_ERROR (Status)) {
+ return Status;
+ }
+ }
+
+ return Status;
+}
+
+EDKII_MEMORY_ACCEPT_PROTOCOL mMemoryAcceptProtocol = {
+ TdxMemoryAccept
+};
+
VOID
SetPcdSettings (
EFI_HOB_PLATFORM_INFO *PlatformInfoHob
@@ -279,6 +369,19 @@ TdxDxeEntryPoint (
NULL
);
+ //
+ // Install MemoryAccept protocol for TDX
+ //
+ Status = gBS->InstallProtocolInterface (
+ &mTdxDxeHandle,
+ &gEdkiiMemoryAcceptProtocolGuid,
+ EFI_NATIVE_INTERFACE,
+ &mMemoryAcceptProtocol
+ );
+ if (EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_ERROR, "Install EdkiiMemoryAcceptProtocol failed.\n"));
+ }
+
//
// Call TDINFO to get actual number of cpus in domain
//
diff --git a/OvmfPkg/TdxDxe/TdxDxe.inf b/OvmfPkg/TdxDxe/TdxDxe.inf
index 3ce8a5c32c98..9793562884c7 100644
--- a/OvmfPkg/TdxDxe/TdxDxe.inf
+++ b/OvmfPkg/TdxDxe/TdxDxe.inf
@@ -52,6 +52,7 @@
gEfiAcpiTableProtocolGuid ## CONSUMES
gEfiMpInitLibMpDepProtocolGuid
gEfiMpInitLibUpDepProtocolGuid
+ gEdkiiMemoryAcceptProtocolGuid
[Pcd]
gUefiOvmfPkgTokenSpaceGuid.PcdPciIoBase
@@ -69,3 +70,4 @@
gEfiMdeModulePkgTokenSpaceGuid.PcdTdxSharedBitMask
gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack
gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved
+ gUefiOvmfPkgTokenSpaceGuid.PcdTdxAcceptPageSize
--
2.29.2.windows.2
^ permalink raw reply related [flat|nested] 29+ messages in thread* [PATCH V4 10/10] OvmfPkg: Call gEdkiiMemoryAcceptProtocolGuid to accept pages
2022-09-13 0:02 [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
` (8 preceding siblings ...)
2022-09-13 0:02 ` [PATCH V4 09/10] OvmfPkg: Realize EdkiiMemoryAcceptProtocol in TdxDxe Min Xu
@ 2022-09-13 0:02 ` Min Xu
2022-09-22 5:25 ` [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
10 siblings, 0 replies; 29+ messages in thread
From: Min Xu @ 2022-09-13 0:02 UTC (permalink / raw)
To: devel
Cc: Min M Xu, Erdem Aktas, James Bottomley, Jiewen Yao, Gerd Hoffmann,
Tom Lendacky
From: Min M Xu <min.m.xu@intel.com>
RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3937
After EdkiiMemoryAcceptProtocol is implemented in TdxDxe driver, we can
call it to accept pages in DXE phase.
Cc: Erdem Aktas <erdemaktas@google.com>
Cc: James Bottomley <jejb@linux.ibm.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Min Xu <min.m.xu@intel.com>
---
.../BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf | 3 +++
.../Library/BaseMemEncryptTdxLib/MemoryEncryption.c | 12 +++++++++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf b/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf
index a8abfec12fa3..11768825f8ca 100644
--- a/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf
+++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf
@@ -42,3 +42,6 @@
[Pcd]
gEfiMdePkgTokenSpaceGuid.PcdConfidentialComputingGuestAttr
+
+[Protocols]
+ gEdkiiMemoryAcceptProtocolGuid
diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
index 9d11c6e4df72..503f626d75c6 100644
--- a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
+++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c
@@ -27,6 +27,8 @@
#include "VirtualMemory.h"
#include <IndustryStandard/Tdx.h>
#include <Library/TdxLib.h>
+#include <Library/UefiBootServicesTableLib.h>
+#include <Protocol/MemoryAccept.h>
#include <ConfidentialComputingGuestAttr.h>
typedef enum {
@@ -517,8 +519,9 @@ SetOrClearSharedBit (
IN UINT64 Length
)
{
- UINT64 AddressEncMask;
- UINT64 Status;
+ UINT64 AddressEncMask;
+ UINT64 Status;
+ EDKII_MEMORY_ACCEPT_PROTOCOL *MemoryAcceptProtocol;
AddressEncMask = GetMemEncryptionAddressMask ();
@@ -539,7 +542,10 @@ SetOrClearSharedBit (
// If changing shared to private, must accept-page again
//
if (Mode == ClearSharedBit) {
- TdAcceptPages (PhysicalAddress, Length / EFI_PAGE_SIZE, EFI_PAGE_SIZE);
+ Status = gBS->LocateProtocol (&gEdkiiMemoryAcceptProtocolGuid, NULL, (VOID **)&MemoryAcceptProtocol);
+ ASSERT (!EFI_ERROR (Status));
+ Status = MemoryAcceptProtocol->AcceptMemory (MemoryAcceptProtocol, PhysicalAddress, Length);
+ ASSERT (!EFI_ERROR (Status));
}
DEBUG ((
--
2.29.2.windows.2
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-09-13 0:02 [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
` (9 preceding siblings ...)
2022-09-13 0:02 ` [PATCH V4 10/10] OvmfPkg: Call gEdkiiMemoryAcceptProtocolGuid to accept pages Min Xu
@ 2022-09-22 5:25 ` Min Xu
2022-09-29 6:56 ` Min Xu
10 siblings, 1 reply; 29+ messages in thread
From: Min Xu @ 2022-09-22 5:25 UTC (permalink / raw)
To: devel@edk2.groups.io, Gao, Liming, Wang, Jian J, Liu, Zhiguang,
Kinney, Michael D
Cc: Gao, Zhichao, Ni, Ray, Aktas, Erdem, Gerd Hoffmann,
James Bottomley, Yao, Jiewen, Tom Lendacky, Gao, Jiaqi
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
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-09-22 5:25 ` [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest Min Xu
@ 2022-09-29 6:56 ` Min Xu
2022-10-10 2:27 ` 回复: " gaoliming
0 siblings, 1 reply; 29+ messages in thread
From: Min Xu @ 2022-09-29 6:56 UTC (permalink / raw)
To: devel@edk2.groups.io, Gao, Liming, Wang, Jian J, Liu, Zhiguang,
Kinney, Michael D
Cc: Gao, Zhichao, Ni, Ray, Aktas, Erdem, Gerd Hoffmann,
James Bottomley, Yao, Jiewen, Tom Lendacky, Gao, Jiaqi
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-09-29 6:56 ` Min Xu
@ 2022-10-10 2:27 ` gaoliming
2022-10-10 3:08 ` [edk2-devel] " Min Xu
2022-10-18 1:13 ` Min Xu
0 siblings, 2 replies; 29+ messages in thread
From: gaoliming @ 2022-10-10 2:27 UTC (permalink / raw)
To: 'Xu, Min M', devel, 'Wang, Jian J',
'Liu, Zhiguang', 'Kinney, Michael D'
Cc: 'Gao, Zhichao', 'Ni, Ray', 'Aktas, Erdem',
'Gerd Hoffmann', 'James Bottomley',
'Yao, Jiewen', 'Tom Lendacky',
'Gao, Jiaqi'
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-10-10 2:27 ` 回复: " gaoliming
@ 2022-10-10 3:08 ` Min Xu
2022-10-10 3:18 ` Ni, Ray
2022-10-18 1:13 ` Min Xu
1 sibling, 1 reply; 29+ messages in thread
From: Min Xu @ 2022-10-10 3:08 UTC (permalink / raw)
To: devel@edk2.groups.io, Dionna Amalie Glaze, Gao, Liming
Cc: Gao, Zhichao, Ni, Ray, Aktas, Erdem, 'Gerd Hoffmann',
'James Bottomley', Yao, Jiewen, 'Tom Lendacky',
Gao, Jiaqi, Wang, Jian J, Liu, Zhiguang, Kinney, Michael D,
Xu, Min M
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-10-10 3:08 ` [edk2-devel] " Min Xu
@ 2022-10-10 3:18 ` Ni, Ray
2022-10-10 15:50 ` Dionna Glaze
0 siblings, 1 reply; 29+ messages in thread
From: Ni, Ray @ 2022-10-10 3:18 UTC (permalink / raw)
To: Xu, Min M, devel@edk2.groups.io, Dionna Amalie Glaze, Gao, Liming
Cc: Gao, Zhichao, Aktas, Erdem, 'Gerd Hoffmann',
'James Bottomley', Yao, Jiewen, 'Tom Lendacky',
Gao, Jiaqi, Wang, Jian J, Liu, Zhiguang, Kinney, Michael D
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-10-10 3:18 ` Ni, Ray
@ 2022-10-10 15:50 ` Dionna Glaze
2022-10-12 5:29 ` Min Xu
0 siblings, 1 reply; 29+ messages in thread
From: Dionna Glaze @ 2022-10-10 15:50 UTC (permalink / raw)
To: Ni, Ray
Cc: Xu, Min M, devel@edk2.groups.io, Gao, Liming, Gao, Zhichao,
Aktas, Erdem, Gerd Hoffmann, James Bottomley, Yao, Jiewen,
Tom Lendacky, Gao, Jiaqi, Wang, Jian J, Liu, Zhiguang,
Kinney, Michael D
>
> 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)
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-10-10 15:50 ` Dionna Glaze
@ 2022-10-12 5:29 ` Min Xu
2022-10-13 5:27 ` Dionna Glaze
0 siblings, 1 reply; 29+ messages in thread
From: Min Xu @ 2022-10-12 5:29 UTC (permalink / raw)
To: Dionna Amalie Glaze, Ni, Ray, Gao, Liming
Cc: devel@edk2.groups.io, Gao, Liming, Gao, Zhichao, Aktas, Erdem,
Gerd Hoffmann, James Bottomley, Yao, Jiewen, Tom Lendacky,
Gao, Jiaqi, Wang, Jian J, Liu, Zhiguang, Kinney, Michael D,
Xu, Min M
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)
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-10-12 5:29 ` Min Xu
@ 2022-10-13 5:27 ` Dionna Glaze
0 siblings, 0 replies; 29+ messages in thread
From: Dionna Glaze @ 2022-10-13 5:27 UTC (permalink / raw)
To: Xu, Min M
Cc: Ni, Ray, Gao, Liming, devel@edk2.groups.io, Gao, Zhichao,
Aktas, Erdem, Gerd Hoffmann, James Bottomley, Yao, Jiewen,
Tom Lendacky, Gao, Jiaqi, Wang, Jian J, Liu, Zhiguang,
Kinney, Michael D
> 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)
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-10-10 2:27 ` 回复: " gaoliming
2022-10-10 3:08 ` [edk2-devel] " Min Xu
@ 2022-10-18 1:13 ` Min Xu
2022-10-19 1:17 ` 回复: " gaoliming
1 sibling, 1 reply; 29+ messages in thread
From: Min Xu @ 2022-10-18 1:13 UTC (permalink / raw)
To: devel@edk2.groups.io, Gao, Liming
Cc: Gao, Zhichao, Ni, Ray, Aktas, Erdem, 'Gerd Hoffmann',
'James Bottomley', Yao, Jiewen, 'Tom Lendacky',
Gao, Jiaqi, Wang, Jian J, Liu, Zhiguang, Kinney, Michael D
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* 回复: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-10-18 1:13 ` Min Xu
@ 2022-10-19 1:17 ` gaoliming
2022-10-19 2:02 ` Min Xu
0 siblings, 1 reply; 29+ messages in thread
From: gaoliming @ 2022-10-19 1:17 UTC (permalink / raw)
To: devel, min.m.xu
Cc: 'Gao, Zhichao', 'Ni, Ray', 'Aktas, Erdem',
'Gerd Hoffmann', 'James Bottomley',
'Yao, Jiewen', 'Tom Lendacky',
'Gao, Jiaqi', 'Wang, Jian J',
'Liu, Zhiguang', 'Kinney, Michael D'
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
>
>
>
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-10-19 1:17 ` 回复: " gaoliming
@ 2022-10-19 2:02 ` Min Xu
2022-10-21 15:58 ` Dionna Glaze
0 siblings, 1 reply; 29+ messages in thread
From: Min Xu @ 2022-10-19 2:02 UTC (permalink / raw)
To: devel@edk2.groups.io, Gao, Liming
Cc: Gao, Zhichao, Ni, Ray, Aktas, Erdem, 'Gerd Hoffmann',
'James Bottomley', Yao, Jiewen, 'Tom Lendacky',
Gao, Jiaqi, Wang, Jian J, Liu, Zhiguang, Kinney, Michael D,
Dionna Amalie Glaze
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-10-19 2:02 ` Min Xu
@ 2022-10-21 15:58 ` Dionna Glaze
2022-10-25 1:07 ` Min Xu
0 siblings, 1 reply; 29+ messages in thread
From: Dionna Glaze @ 2022-10-21 15:58 UTC (permalink / raw)
To: Xu, Min M
Cc: devel@edk2.groups.io, Gao, Liming, Gao, Zhichao, Ni, Ray,
Aktas, Erdem, Gerd Hoffmann, James Bottomley, Yao, Jiewen,
Tom Lendacky, Gao, Jiaqi, Wang, Jian J, Liu, Zhiguang,
Kinney, Michael D, Ard Biesheuvel
> > 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)
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-10-21 15:58 ` Dionna Glaze
@ 2022-10-25 1:07 ` Min Xu
2022-10-26 1:27 ` 回复: " gaoliming
0 siblings, 1 reply; 29+ messages in thread
From: Min Xu @ 2022-10-25 1:07 UTC (permalink / raw)
To: Dionna Amalie Glaze, Gao, Liming
Cc: devel@edk2.groups.io, Gao, Zhichao, Ni, Ray, Aktas, Erdem,
Gerd Hoffmann, James Bottomley, Yao, Jiewen, Tom Lendacky,
Gao, Jiaqi, Wang, Jian J, Liu, Zhiguang, Kinney, Michael D,
Ard Biesheuvel, Xu, Min M
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)
^ permalink raw reply [flat|nested] 29+ messages in thread
* 回复: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-10-25 1:07 ` Min Xu
@ 2022-10-26 1:27 ` gaoliming
2022-10-26 13:35 ` Min Xu
0 siblings, 1 reply; 29+ messages in thread
From: gaoliming @ 2022-10-26 1:27 UTC (permalink / raw)
To: devel, min.m.xu, 'Dionna Amalie Glaze'
Cc: 'Gao, Zhichao', 'Ni, Ray', 'Aktas, Erdem',
'Gerd Hoffmann', 'James Bottomley',
'Yao, Jiewen', 'Tom Lendacky',
'Gao, Jiaqi', 'Wang, Jian J',
'Liu, Zhiguang', 'Kinney, Michael D',
'Ard Biesheuvel'
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)
>
>
>
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-10-26 1:27 ` 回复: " gaoliming
@ 2022-10-26 13:35 ` Min Xu
2022-11-01 1:18 ` 回复: " gaoliming
0 siblings, 1 reply; 29+ messages in thread
From: Min Xu @ 2022-10-26 13:35 UTC (permalink / raw)
To: devel@edk2.groups.io, Gao, Liming, 'Dionna Amalie Glaze'
Cc: Gao, Zhichao, Ni, Ray, Aktas, Erdem, 'Gerd Hoffmann',
'James Bottomley', Yao, Jiewen, 'Tom Lendacky',
Gao, Jiaqi, Wang, Jian J, Liu, Zhiguang, Kinney, Michael D,
'Ard Biesheuvel'
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* 回复: [edk2-devel] 回复: [PATCH V4 00/10] Introduce Lazy-accept for Tdx guest
2022-10-26 13:35 ` Min Xu
@ 2022-11-01 1:18 ` gaoliming
0 siblings, 0 replies; 29+ messages in thread
From: gaoliming @ 2022-11-01 1:18 UTC (permalink / raw)
To: devel, min.m.xu, 'Dionna Amalie Glaze'
Cc: 'Gao, Zhichao', 'Ni, Ray', 'Aktas, Erdem',
'Gerd Hoffmann', 'James Bottomley',
'Yao, Jiewen', 'Tom Lendacky',
'Gao, Jiaqi', 'Wang, Jian J',
'Liu, Zhiguang', 'Kinney, Michael D',
'Ard Biesheuvel'
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
>
>
>
>
>
>
^ permalink raw reply [flat|nested] 29+ messages in thread