* [edk2-devel] [PATCH V1 0/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA @ 2023-10-27 0:57 sunceping 2023-10-27 0:57 ` [edk2-devel] [PATCH V1 1/2] OvmfPkg/BaseMemEncryptTdxLib: Add TdVmCallMapGPA sunceping 2023-10-27 0:57 ` [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA sunceping 0 siblings, 2 replies; 10+ messages in thread From: sunceping @ 2023-10-27 0:57 UTC (permalink / raw) To: devel Cc: sunceping, Erdem Aktas, James Bottomley, Jiewen Yao, Min Xu, Tom Lendacky, Michael Roth, Gerd Hoffmann REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4572 According to section 3.2 of the [GHCI] documentation, if the result is "TDG.VP.VMCALL_RETRY" for TDG.VP.VMCALL, TD must retry the mapping for the pages in the region starting at the GPA specified in r11. Currently, TDVF does not properly handle the retry results of MapGPA. For this, TDVF should add the API to return the value in R11 and must retry the mapping for the pages by the value. How to verify the retry for MapGPA in TDVF: Note: Since the range size of MapGPA in QEMU is limited to 64MB and TDVF always maps 1.5GB( 2GB~3.5GB) MMIO to shared-memory for TD guest, the retry action is triggered always. Pre-Config: QEMU: https://github.com/intel/qemu-tdx/tree/tdx-qemu-upstream | tag: tdx-qemu-upstream-2023.10.20-v8.1.0 KERNEL: https://github.com/intel/tdx/tree/kvm-upstream-2023.10.16-v6.6-rc2 Step: Boot with TD guest and check the log with TdVmcall(MAPGPA). Would See the line as below: TdxDxe:SetMemorySharedOrPrivate: Cr3Base=0x0 Physical=0x80000000 Length=0x60000000 Mode=Shared SetOrClearSharedBit: TdVmcall(MAPGPA) Retry PhysicalAddress is 8000080000000, MapGpaRetryaddr is 8000084000000 Reference: [GHCI]: TDX Guest-Host-Communication Interface v1.0 https://cdrdv2.intel.com/v1/dl/getContent/726790 Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Ceping Sun <cepingx.sun@intel.com> Ceping Sun (2): OvmfPkg/BaseMemEncryptTdxLib: Add TdVmCallMapGPA OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA .../BaseMemEncryptTdxLib.inf | 1 + .../BaseMemEncryptTdxLib/MemoryEncryption.c | 55 +++++++- .../X64/TdVmCallMapGPA.nasm | 130 ++++++++++++++++++ 3 files changed, 185 insertions(+), 1 deletion(-) create mode 100644 OvmfPkg/Library/BaseMemEncryptTdxLib/X64/TdVmCallMapGPA.nasm -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110157): https://edk2.groups.io/g/devel/message/110157 Mute This Topic: https://groups.io/mt/102212634/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=- ^ permalink raw reply [flat|nested] 10+ messages in thread
* [edk2-devel] [PATCH V1 1/2] OvmfPkg/BaseMemEncryptTdxLib: Add TdVmCallMapGPA 2023-10-27 0:57 [edk2-devel] [PATCH V1 0/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA sunceping @ 2023-10-27 0:57 ` sunceping 2023-10-27 0:57 ` [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA sunceping 1 sibling, 0 replies; 10+ messages in thread From: sunceping @ 2023-10-27 0:57 UTC (permalink / raw) To: devel Cc: Ceping Sun, Erdem Aktas, James Bottomley, Jiewen Yao, Min Xu, Tom Lendacky, Michael Roth, Gerd Hoffmann From: Ceping Sun <cepingx.sun@intel.com> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4572 According to section 3.2 of the [GHCI] spec, if the return status is "TDG.VP.VMCALL_RETRY", TD must retry this operation for the pages in the region starting at the GPA specified in R11. Currently, TDVF has not handled the retry results of MapGPA. For this, TDVF should add the API to output the GPA at which MapGPA failed in R11 to handle the retry results. Reference: [GHCI]: TDX Guest-Host-Communication Interface v1.0 https://cdrdv2.intel.com/v1/dl/getContent/726790 Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Ceping Sun <cepingx.sun@intel.com> --- .../BaseMemEncryptTdxLib/MemoryEncryption.c | 19 +++ .../X64/TdVmCallMapGPA.nasm | 130 ++++++++++++++++++ 2 files changed, 149 insertions(+) create mode 100644 OvmfPkg/Library/BaseMemEncryptTdxLib/X64/TdVmCallMapGPA.nasm diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c index a01dc98852b8..b47f56b391a5 100644 --- a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c +++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c @@ -38,6 +38,25 @@ typedef enum { STATIC PAGE_TABLE_POOL *mPageTablePool = NULL; +/** + This function is used to help request the host VMM to map a GPA range as + private or shared-memory mappings. + @param[in] Address 4K aligned start GPA of address range. + @param[in] Length Size of GPA region to be mapped. + @param[in,out] Results Returned result of the GPA at which MapGPA failed + + @return 0 A successful mapping + @return Other Some errors occurred while mapping +**/ + +UINTN +EFIAPI +TdVmCallMapGPA ( + IN UINT64 Address, + IN UINT64 Length, + IN OUT VOID *Results + ); + /** Returns boolean to indicate whether to indicate which, if any, memory encryption is enabled diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/X64/TdVmCallMapGPA.nasm b/OvmfPkg/Library/BaseMemEncryptTdxLib/X64/TdVmCallMapGPA.nasm new file mode 100644 index 000000000000..37186bd0a0dd --- /dev/null +++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/X64/TdVmCallMapGPA.nasm @@ -0,0 +1,130 @@ +;------------------------------------------------------------------------------ +;* +;* Copyright (c) 2020 - 2021, Intel Corporation. All rights reserved.<BR> +;* SPDX-License-Identifier: BSD-2-Clause-Patent +;* +;* +;------------------------------------------------------------------------------ + +DEFAULT REL +SECTION .text + +%define TDVMCALL_EXPOSE_REGS_MASK 0xffec +%define TDVMCALL 0x0 +%define TDVMCALL_MAPGPA 0x10001 +%define TDVMCALL_STATUS_RETRY 0x1 + +%macro tdcall 0 + db 0x66,0x0f,0x01,0xcc +%endmacro + +%macro tdcall_push_regs 0 + push rbp + mov rbp, rsp + push r15 + push r14 + push r13 + push r12 + push rbx + push rsi + push rdi +%endmacro + +%macro tdcall_pop_regs 0 + pop rdi + pop rsi + pop rbx + pop r12 + pop r13 + pop r14 + pop r15 + pop rbp +%endmacro + +%macro tdcall_regs_preamble 2 + mov rax, %1 + + xor rcx, rcx + mov ecx, %2 + + ; R10 = 0 (standard TDVMCALL) + + xor r10d, r10d + + ; Zero out unused (for standard TDVMCALL) registers to avoid leaking + ; secrets to the VMM. + + xor ebx, ebx + xor esi, esi + xor edi, edi + + xor edx, edx + xor ebp, ebp + xor r8d, r8d + xor r9d, r9d +%endmacro + +%macro tdcall_regs_postamble 0 + xor ebx, ebx + xor esi, esi + xor edi, edi + + xor ecx, ecx + xor edx, edx + xor r8d, r8d + xor r9d, r9d + xor r10d, r10d + xor r11d, r11d +%endmacro + +;------------------------------------------------------------------------------ +; 0 => RAX = TDCALL leaf +; M => RCX = TDVMCALL register behavior +; 1 => R10 = standard vs. vendor +; 0xa => R11 = TDVMCALL function / MapGPA +; RCX => R12 = p1 +; RDX => R13 = p2 + +; UINT64 +; EFIAPI +; TdVmCallMapGPA ( +; UINT64 Address, // Rcx +; UINT64 Length, // Rdx +; UINT64 *Results // r8 +; ) +global ASM_PFX(TdVmCallMapGPA) +ASM_PFX(TdVmCallMapGPA): + tdcall_push_regs + + mov r11, TDVMCALL_MAPGPA + mov r12, rcx + mov r13, rdx + + push r8 + + tdcall_regs_preamble TDVMCALL, TDVMCALL_EXPOSE_REGS_MASK + + tdcall + + ; ignore return dataif TDCALL reports failure. + test rax, rax + jnz .no_return_data + + ; Propagate TDVMCALL success/failure to return value. + mov rax, r10 + + ; Retrieve the Val pointer. + pop r8 + test r8, r8 + jz .no_return_data + + ; On Retry, propagate TDVMCALL output value to output param + cmp rax, TDVMCALL_STATUS_RETRY + jnz .no_return_data + mov [r8], r11 +.no_return_data: + tdcall_regs_postamble + + tdcall_pop_regs + + ret -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110158): https://edk2.groups.io/g/devel/message/110158 Mute This Topic: https://groups.io/mt/102212638/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=- ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA 2023-10-27 0:57 [edk2-devel] [PATCH V1 0/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA sunceping 2023-10-27 0:57 ` [edk2-devel] [PATCH V1 1/2] OvmfPkg/BaseMemEncryptTdxLib: Add TdVmCallMapGPA sunceping @ 2023-10-27 0:57 ` sunceping 2023-10-27 11:04 ` Gerd Hoffmann 2023-10-27 16:44 ` Erdem Aktas via groups.io 1 sibling, 2 replies; 10+ messages in thread From: sunceping @ 2023-10-27 0:57 UTC (permalink / raw) To: devel Cc: Ceping Sun, Erdem Aktas, James Bottomley, Jiewen Yao, Min Xu, Tom Lendacky, Michael Roth, Gerd Hoffmann From: Ceping Sun <cepingx.sun@intel.com> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4572 According to section 3.2 of the [GHCI] document, if the result of MapGPA is "TDG.VP.VMCALL_RETRY", TDVF must retry mapping for pages in that region, starting with the GPA specified in R11. Reference: [GHCI]: TDX Guest-Host-Communication Interface v1.0 https://cdrdv2.intel.com/v1/dl/getContent/726790 Cc: Erdem Aktas <erdemaktas@google.com> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Min Xu <min.m.xu@intel.com> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Michael Roth <michael.roth@amd.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Ceping Sun <cepingx.sun@intel.com> --- .../BaseMemEncryptTdxLib.inf | 1 + .../BaseMemEncryptTdxLib/MemoryEncryption.c | 36 ++++++++++++++++++- 2 files changed, 36 insertions(+), 1 deletion(-) diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf b/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf index 11768825f8ca..742b65a289ce 100644 --- a/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf +++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf @@ -30,6 +30,7 @@ [Sources] VirtualMemory.h MemoryEncryption.c + X64/TdVmCallMapGPA.nasm [LibraryClasses] BaseLib diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c index b47f56b391a5..1f29f9194c30 100644 --- a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c +++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c @@ -38,6 +38,10 @@ typedef enum { STATIC PAGE_TABLE_POOL *mPageTablePool = NULL; +#define TDVMCALL_STATUS_RETRY 0x1 + +#define MAX_RETRIES_PER_PAGE 3 + /** This function is used to help request the host VMM to map a GPA range as private or shared-memory mappings. @@ -546,6 +550,13 @@ SetOrClearSharedBit ( EFI_STATUS Status; EDKII_MEMORY_ACCEPT_PROTOCOL *MemoryAcceptProtocol; + UINT64 MapGpaRetryaddr; + UINT32 RetryCount; + UINT64 EndAddress; + + MapGpaRetryaddr = 0; + RetryCount = 0; + AddressEncMask = GetMemEncryptionAddressMask (); // @@ -559,7 +570,30 @@ SetOrClearSharedBit ( PhysicalAddress &= ~AddressEncMask; } - TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0, NULL); + while (RetryCount < MAX_RETRIES_PER_PAGE) { + TdStatus = TdVmCallMapGPA (PhysicalAddress, Length, &MapGpaRetryaddr); + if (TdStatus != TDVMCALL_STATUS_RETRY) { + break; + } + + DEBUG ((DEBUG_VERBOSE, "%a: TdVmcall(MAPGPA) Retry PhysicalAddress is %llx, MapGpaRetryaddr is %llx\n", __func__, PhysicalAddress, MapGpaRetryaddr)); + + EndAddress = PhysicalAddress + Length; + if ((MapGpaRetryaddr < PhysicalAddress) || (MapGpaRetryaddr > EndAddress)) { + DEBUG ((DEBUG_ERROR, "%a: TdVmcall(MAPGPA) failed Retry PhysicalAddress is %llx, MapGpaRetryaddr is %llx\n", __func__, PhysicalAddress, MapGpaRetryaddr)); + break; + } + + if (MapGpaRetryaddr == PhysicalAddress) { + RetryCount++; + continue; + } + + PhysicalAddress = MapGpaRetryaddr; + Length = EndAddress - PhysicalAddress; + RetryCount = 0; + } + if (TdStatus != 0) { DEBUG ((DEBUG_ERROR, "%a: TdVmcall(MAPGPA) failed with %llx\n", __func__, TdStatus)); ASSERT (FALSE); -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110159): https://edk2.groups.io/g/devel/message/110159 Mute This Topic: https://groups.io/mt/102212640/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=- ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA 2023-10-27 0:57 ` [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA sunceping @ 2023-10-27 11:04 ` Gerd Hoffmann 2023-10-30 2:26 ` sunceping 2023-10-27 16:44 ` Erdem Aktas via groups.io 1 sibling, 1 reply; 10+ messages in thread From: Gerd Hoffmann @ 2023-10-27 11:04 UTC (permalink / raw) To: sunceping Cc: devel, Erdem Aktas, James Bottomley, Jiewen Yao, Min Xu, Tom Lendacky, Michael Roth Hi, > + while (RetryCount < MAX_RETRIES_PER_PAGE) { > + TdStatus = TdVmCallMapGPA (PhysicalAddress, Length, &MapGpaRetryaddr); > + if (TdStatus != TDVMCALL_STATUS_RETRY) { > + break; > + } > + > + DEBUG ((DEBUG_VERBOSE, "%a: TdVmcall(MAPGPA) Retry PhysicalAddress is %llx, MapGpaRetryaddr is %llx\n", __func__, PhysicalAddress, MapGpaRetryaddr)); > + > + EndAddress = PhysicalAddress + Length; The end address doesn't change, you can move that out of the loop. > + if ((MapGpaRetryaddr < PhysicalAddress) || (MapGpaRetryaddr > EndAddress)) { > + DEBUG ((DEBUG_ERROR, "%a: TdVmcall(MAPGPA) failed Retry PhysicalAddress is %llx, MapGpaRetryaddr is %llx\n", __func__, PhysicalAddress, MapGpaRetryaddr)); > + break; > + } The error message is misleading. The actual problem is that the 'PhysicalAddress <= MapGpaRetryaddr <= EndAddress' sanity check failed. take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110202): https://edk2.groups.io/g/devel/message/110202 Mute This Topic: https://groups.io/mt/102212640/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA 2023-10-27 11:04 ` Gerd Hoffmann @ 2023-10-30 2:26 ` sunceping 0 siblings, 0 replies; 10+ messages in thread From: sunceping @ 2023-10-30 2:26 UTC (permalink / raw) To: Gerd Hoffmann Cc: devel@edk2.groups.io, Aktas, Erdem, James Bottomley, Yao, Jiewen, Xu, Min M, Tom Lendacky, Michael Roth On Friday, October 27, 2023 7:05 PM, Gerd Hoffmann wrote: > > + while (RetryCount < MAX_RETRIES_PER_PAGE) { > > + TdStatus = TdVmCallMapGPA (PhysicalAddress, Length, > &MapGpaRetryaddr); > > + if (TdStatus != TDVMCALL_STATUS_RETRY) { > > + break; > > + } > > + > > + DEBUG ((DEBUG_VERBOSE, "%a: TdVmcall(MAPGPA) Retry > > + PhysicalAddress is %llx, MapGpaRetryaddr is %llx\n", __func__, > > + PhysicalAddress, MapGpaRetryaddr)); > > + > > + EndAddress = PhysicalAddress + Length; > > The end address doesn't change, you can move that out of the loop. It would be updated in next version. > > > + if ((MapGpaRetryaddr < PhysicalAddress) || (MapGpaRetryaddr > > EndAddress)) { > > + DEBUG ((DEBUG_ERROR, "%a: TdVmcall(MAPGPA) failed Retry > PhysicalAddress is %llx, MapGpaRetryaddr is %llx\n", __func__, > PhysicalAddress, MapGpaRetryaddr)); > > + break; > > + } > > The error message is misleading. The actual problem is that the > 'PhysicalAddress <= MapGpaRetryaddr <= EndAddress' sanity check failed. The error message would be updated in next version. > Thanks Ceping -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110283): https://edk2.groups.io/g/devel/message/110283 Mute This Topic: https://groups.io/mt/102212640/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA 2023-10-27 0:57 ` [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA sunceping 2023-10-27 11:04 ` Gerd Hoffmann @ 2023-10-27 16:44 ` Erdem Aktas via groups.io 2023-10-30 6:41 ` sunceping 1 sibling, 1 reply; 10+ messages in thread From: Erdem Aktas via groups.io @ 2023-10-27 16:44 UTC (permalink / raw) To: sunceping Cc: devel, James Bottomley, Jiewen Yao, Min Xu, Tom Lendacky, Michael Roth, Gerd Hoffmann [-- Attachment #1: Type: text/plain, Size: 4633 bytes --] Hi, This should be the [PATCH V1 2/2] I assume? On Thu, Oct 26, 2023 at 5:58 PM sunceping <cepingx.sun@intel.com> wrote: > From: Ceping Sun <cepingx.sun@intel.com> > > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4572 > > According to section 3.2 of the [GHCI] document, if the result of MapGPA > is "TDG.VP.VMCALL_RETRY", TDVF must retry mapping for pages in that region, > starting with the GPA specified in R11. > > Reference: > [GHCI]: TDX Guest-Host-Communication Interface v1.0 > https://cdrdv2.intel.com/v1/dl/getContent/726790 > > Cc: Erdem Aktas <erdemaktas@google.com> > Cc: James Bottomley <jejb@linux.ibm.com> > Cc: Jiewen Yao <jiewen.yao@intel.com> > Cc: Min Xu <min.m.xu@intel.com> > Cc: Tom Lendacky <thomas.lendacky@amd.com> > Cc: Michael Roth <michael.roth@amd.com> > Cc: Gerd Hoffmann <kraxel@redhat.com> > Signed-off-by: Ceping Sun <cepingx.sun@intel.com> > --- > .../BaseMemEncryptTdxLib.inf | 1 + > .../BaseMemEncryptTdxLib/MemoryEncryption.c | 36 ++++++++++++++++++- > 2 files changed, 36 insertions(+), 1 deletion(-) > > diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf > b/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf > index 11768825f8ca..742b65a289ce 100644 > --- a/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf > +++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/BaseMemEncryptTdxLib.inf > @@ -30,6 +30,7 @@ > [Sources] > VirtualMemory.h > MemoryEncryption.c > + X64/TdVmCallMapGPA.nasm > I do not think we need another TdVmCallMapGPA definition, do we? > > [LibraryClasses] > BaseLib > diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c > b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c > index b47f56b391a5..1f29f9194c30 100644 > --- a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c > +++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c > @@ -38,6 +38,10 @@ typedef enum { > > STATIC PAGE_TABLE_POOL *mPageTablePool = NULL; > > +#define TDVMCALL_STATUS_RETRY 0x1 > + > +#define MAX_RETRIES_PER_PAGE 3 > + > /** > This function is used to help request the host VMM to map a GPA range as > private or shared-memory mappings. > @@ -546,6 +550,13 @@ SetOrClearSharedBit ( > EFI_STATUS Status; > EDKII_MEMORY_ACCEPT_PROTOCOL *MemoryAcceptProtocol; > > + UINT64 MapGpaRetryaddr; > Should be replaced with MapGpaRetryAddr for consistency in variable name casing style ? > + UINT32 RetryCount; > + UINT64 EndAddress; > + > + MapGpaRetryaddr = 0; > + RetryCount = 0; > + > AddressEncMask = GetMemEncryptionAddressMask (); > > // > @@ -559,7 +570,30 @@ SetOrClearSharedBit ( > PhysicalAddress &= ~AddressEncMask; > } > > - TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0, > NULL); > + while (RetryCount < MAX_RETRIES_PER_PAGE) { > + TdStatus = TdVmCallMapGPA (PhysicalAddress, Length, &MapGpaRetryaddr); > Why not this? TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0, &MapGpaRetryaddr); > + if (TdStatus != TDVMCALL_STATUS_RETRY) { > + break; > + } > + > + DEBUG ((DEBUG_VERBOSE, "%a: TdVmcall(MAPGPA) Retry PhysicalAddress is > %llx, MapGpaRetryaddr is %llx\n", __func__, PhysicalAddress, > MapGpaRetryaddr)); > + > + EndAddress = PhysicalAddress + Length; > + if ((MapGpaRetryaddr < PhysicalAddress) || (MapGpaRetryaddr > > EndAddress)) { > should be? if ((MapGpaRetryaddr < PhysicalAddress) || (MapGpaRetryaddr >= EndAddress)) > + DEBUG ((DEBUG_ERROR, "%a: TdVmcall(MAPGPA) failed Retry > PhysicalAddress is %llx, MapGpaRetryaddr is %llx\n", __func__, > PhysicalAddress, MapGpaRetryaddr)); > + break; > + } > + > + if (MapGpaRetryaddr == PhysicalAddress) { > + RetryCount++; > + continue; > + } > + > + PhysicalAddress = MapGpaRetryaddr; > + Length = EndAddress - PhysicalAddress; > + RetryCount = 0; > + } > + > if (TdStatus != 0) { > DEBUG ((DEBUG_ERROR, "%a: TdVmcall(MAPGPA) failed with %llx\n", > __func__, TdStatus)); > ASSERT (FALSE); > -- > 2.34.1 > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110223): https://edk2.groups.io/g/devel/message/110223 Mute This Topic: https://groups.io/mt/102212640/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=- [-- Attachment #2: Type: text/html, Size: 7099 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA 2023-10-27 16:44 ` Erdem Aktas via groups.io @ 2023-10-30 6:41 ` sunceping 2023-10-31 0:45 ` Erdem Aktas via groups.io 0 siblings, 1 reply; 10+ messages in thread From: sunceping @ 2023-10-30 6:41 UTC (permalink / raw) To: Aktas, Erdem Cc: devel@edk2.groups.io, James Bottomley, Yao, Jiewen, Xu, Min M, Tom Lendacky, Michael Roth, Gerd Hoffmann [-- Attachment #1: Type: text/plain, Size: 3488 bytes --] On Saturday, October 28, 2023 12:45 AM, Erdem Aktas wrote: This should be the [PATCH V1 2/2] I assume? Yes, the name is same with [PATCH v1 0/2] , may be confusion, I would update in next version to avoid the same title name. On Thu, Oct 26, 2023 at 5:58 PM sunceping <cepingx.sun@intel.com<mailto:cepingx.sun@intel.com>> wrote: [Sources] VirtualMemory.h MemoryEncryption.c + X64/TdVmCallMapGPA.nasm I do not think we need another TdVmCallMapGPA definition, do we? Currently, the TdVmCall always clears the R11 if the return code is not successful, which means we need to change TdVmCall if we don't add TdVmCallMapGPA. Refer the GHCI Spec , if the returns code is not successful, the R11 value is not valid for the sub-functions except MapGPA, which means TdVmCall should clear the value on unsuccessful returns and only save the value if MapGPA returns unsuccessfully. If an update is required, the logic in TdVmCall could be complex. [LibraryClasses] BaseLib diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c index b47f56b391a5..1f29f9194c30 100644 --- a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c +++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c @@ -38,6 +38,10 @@ typedef enum { STATIC PAGE_TABLE_POOL *mPageTablePool = NULL; +#define TDVMCALL_STATUS_RETRY 0x1 + +#define MAX_RETRIES_PER_PAGE 3 + /** This function is used to help request the host VMM to map a GPA range as private or shared-memory mappings. @@ -546,6 +550,13 @@ SetOrClearSharedBit ( EFI_STATUS Status; EDKII_MEMORY_ACCEPT_PROTOCOL *MemoryAcceptProtocol; + UINT64 MapGpaRetryaddr; Should be replaced with MapGpaRetryAddr for consistency in variable name casing style ? Yes, it would be updated in next version. + UINT32 RetryCount; + UINT64 EndAddress; + + MapGpaRetryaddr = 0; + RetryCount = 0; + AddressEncMask = GetMemEncryptionAddressMask (); // @@ -559,7 +570,30 @@ SetOrClearSharedBit ( PhysicalAddress &= ~AddressEncMask; } - TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0, NULL); + while (RetryCount < MAX_RETRIES_PER_PAGE) { + TdStatus = TdVmCallMapGPA (PhysicalAddress, Length, &MapGpaRetryaddr); Why not this? TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0, &MapGpaRetryaddr); The TdVmCall always clears the R11 value when unsuccessful returns as above comments, therefor add the TdVmCallMapGPA to handle it. + if (TdStatus != TDVMCALL_STATUS_RETRY) { + break; + } + + DEBUG ((DEBUG_VERBOSE, "%a: TdVmcall(MAPGPA) Retry PhysicalAddress is %llx, MapGpaRetryaddr is %llx\n", __func__, PhysicalAddress, MapGpaRetryaddr)); + + EndAddress = PhysicalAddress + Length; + if ((MapGpaRetryaddr < PhysicalAddress) || (MapGpaRetryaddr > EndAddress)) { should be? if ((MapGpaRetryaddr < PhysicalAddress) || (MapGpaRetryaddr >= EndAddress)) Yes, that’s right, it would be updated in next version. Thanks Ceping -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110291): https://edk2.groups.io/g/devel/message/110291 Mute This Topic: https://groups.io/mt/102212640/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=- [-- Attachment #2: Type: text/html, Size: 7481 bytes --] ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA 2023-10-30 6:41 ` sunceping @ 2023-10-31 0:45 ` Erdem Aktas via groups.io 2023-10-31 7:46 ` sunceping 2023-11-02 9:25 ` sunceping 0 siblings, 2 replies; 10+ messages in thread From: Erdem Aktas via groups.io @ 2023-10-31 0:45 UTC (permalink / raw) To: Sun, CepingX Cc: devel@edk2.groups.io, James Bottomley, Yao, Jiewen, Xu, Min M, Tom Lendacky, Michael Roth, Gerd Hoffmann On Sun, Oct 29, 2023 at 11:42 PM Sun, CepingX <cepingx.sun@intel.com> wrote: > > On Saturday, October 28, 2023 12:45 AM, Erdem Aktas wrote: > This should be the [PATCH V1 2/2] I assume? > Yes, the name is same with [PATCH v1 0/2] , may be confusion, I would update in next version to avoid the same title name. > > > On Thu, Oct 26, 2023 at 5:58 PM sunceping <cepingx.sun@intel.com> wrote: > [Sources] > VirtualMemory.h > MemoryEncryption.c > + X64/TdVmCallMapGPA.nasm > I do not think we need another TdVmCallMapGPA definition, do we? > Currently, the TdVmCall always clears the R11 if the return code is not successful, which means we need to change TdVmCall if we don't add TdVmCallMapGPA. > Refer the GHCI Spec , if the returns code is not successful, the R11 value is not valid for the sub-functions except MapGPA, which means TdVmCall should clear the value on > unsuccessful returns and only save the value if MapGPA returns unsuccessfully. If an update is required, the logic in TdVmCall could be complex. It seems like TdVmCallMapGPA function is actually duplicating most of the code that the TdVmCall function is already doing. According to the spec, R11 has meaningful data when mapgpa has RETRY, GPA_IN_USE or ALIGN_ERROR. I do not think the TdVmCall change logic would be complex (or not more than what TdVmCallMapGPA is already doing). I would like to see what others are saying on this. > > [LibraryClasses] > BaseLib > diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c > index b47f56b391a5..1f29f9194c30 100644 > --- a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c > +++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c > @@ -38,6 +38,10 @@ typedef enum { > > STATIC PAGE_TABLE_POOL *mPageTablePool = NULL; > > +#define TDVMCALL_STATUS_RETRY 0x1 > + > +#define MAX_RETRIES_PER_PAGE 3 > + > /** > This function is used to help request the host VMM to map a GPA range as > private or shared-memory mappings. > @@ -546,6 +550,13 @@ SetOrClearSharedBit ( > EFI_STATUS Status; > EDKII_MEMORY_ACCEPT_PROTOCOL *MemoryAcceptProtocol; > > + UINT64 MapGpaRetryaddr; > Should be replaced with MapGpaRetryAddr for consistency in variable name casing style ? > Yes, it would be updated in next version. > > + UINT32 RetryCount; > + UINT64 EndAddress; > + > + MapGpaRetryaddr = 0; > + RetryCount = 0; > + > AddressEncMask = GetMemEncryptionAddressMask (); > > // > @@ -559,7 +570,30 @@ SetOrClearSharedBit ( > PhysicalAddress &= ~AddressEncMask; > } > > - TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0, NULL); > + while (RetryCount < MAX_RETRIES_PER_PAGE) { > + TdStatus = TdVmCallMapGPA (PhysicalAddress, Length, &MapGpaRetryaddr); > Why not this? > TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0, &MapGpaRetryaddr); > The TdVmCall always clears the R11 value when unsuccessful returns as above comments, therefor add the TdVmCallMapGPA to handle it. right, the tdvmcall does not handle the R11 correctly for mapGPA. I think it should be an easy fix in that function instead of creating a whole copy of that function. Is there a reason why we think it is complicated? > > + if (TdStatus != TDVMCALL_STATUS_RETRY) { > + break; > + } > + > + DEBUG ((DEBUG_VERBOSE, "%a: TdVmcall(MAPGPA) Retry PhysicalAddress is %llx, MapGpaRetryaddr is %llx\n", __func__, PhysicalAddress, MapGpaRetryaddr)); > + > + EndAddress = PhysicalAddress + Length; > + if ((MapGpaRetryaddr < PhysicalAddress) || (MapGpaRetryaddr > EndAddress)) { > should be? > if ((MapGpaRetryaddr < PhysicalAddress) || (MapGpaRetryaddr >= EndAddress)) > Yes, that’s right, it would be updated in next version. > > Thanks > Ceping > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110350): https://edk2.groups.io/g/devel/message/110350 Mute This Topic: https://groups.io/mt/102212640/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=- ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA 2023-10-31 0:45 ` Erdem Aktas via groups.io @ 2023-10-31 7:46 ` sunceping 2023-11-02 9:25 ` sunceping 1 sibling, 0 replies; 10+ messages in thread From: sunceping @ 2023-10-31 7:46 UTC (permalink / raw) To: Aktas, Erdem, Gerd Hoffmann Cc: devel@edk2.groups.io, James Bottomley, Yao, Jiewen, Xu, Min M, Tom Lendacky, Michael Roth, Sun, CepingX [-- Attachment #1: Type: text/plain, Size: 3474 bytes --] On Tuesday, October 31, 2023 8:45 AM, Erdem Aktas wrote: > On Sun, Oct 29, 2023 at 11:42 PM Sun, CepingX <cepingx.sun@intel.com<mailto:cepingx.sun@intel.com>> > wrote: > > > > On Saturday, October 28, 2023 12:45 AM, Erdem Aktas wrote: > > This should be the [PATCH V1 2/2] I assume? > > Yes, the name is same with [PATCH v1 0/2] , may be confusion, I would > update in next version to avoid the same title name. > > > > > > On Thu, Oct 26, 2023 at 5:58 PM sunceping <cepingx.sun@intel.com<mailto:cepingx.sun@intel.com>> wrote: > > [Sources] > > VirtualMemory.h > > MemoryEncryption.c > > + X64/TdVmCallMapGPA.nasm > > I do not think we need another TdVmCallMapGPA definition, do we? > > Currently, the TdVmCall always clears the R11 if the return code is not > successful, which means we need to change TdVmCall if we don't add > TdVmCallMapGPA. > > Refer the GHCI Spec , if the returns code is not successful, the R11 > > value is not valid for the sub-functions except MapGPA, which means > TdVmCall should clear the value on unsuccessful returns and only save the > value if MapGPA returns unsuccessfully. If an update is required, the logic in > TdVmCall could be complex. > > It seems like TdVmCallMapGPA function is actually duplicating most of the > code that the TdVmCall function is already doing. > According to the spec, R11 has meaningful data when mapgpa has RETRY, > GPA_IN_USE or ALIGN_ERROR. > I do not think the TdVmCall change logic would be complex (or not more > than what TdVmCallMapGPA is already doing). > I would like to see what others are saying on this. > Yes, we can wait for other's comments. @Gerd Hoffmann<mailto:kraxel@redhat.com> , Could you help add a comment? > > - TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, > > 0, NULL); > > + while (RetryCount < MAX_RETRIES_PER_PAGE) { > > + TdStatus = TdVmCallMapGPA (PhysicalAddress, Length, > > + &MapGpaRetryaddr); > > Why not this? > > TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0, > > &MapGpaRetryaddr); The TdVmCall always clears the R11 value when > unsuccessful returns as above comments, therefor add the > TdVmCallMapGPA to handle it. > right, the tdvmcall does not handle the R11 correctly for mapGPA. I think it > should be an easy fix in that function instead of creating a whole copy of that > function. > Is there a reason why we think it is complicated? If an update is required, the TdVmCall has to add a flag or value to indicate the MapGPA and always compares the return code before clearing. This indicates that additional code must be developed specifically to handle the results and solely for MapGPA at this time, it would make the code seems complex and not easy extend in the future. Based on the above considerations, we extract the code for MapGPA as an individual function, that' s easy to understand and extend for other results in the future. Thanks Ceping -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110383): https://edk2.groups.io/g/devel/message/110383 Mute This Topic: https://groups.io/mt/102212640/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=- [-- Attachment #2: Type: text/html, Size: 8028 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA 2023-10-31 0:45 ` Erdem Aktas via groups.io 2023-10-31 7:46 ` sunceping @ 2023-11-02 9:25 ` sunceping 1 sibling, 0 replies; 10+ messages in thread From: sunceping @ 2023-11-02 9:25 UTC (permalink / raw) To: Aktas, Erdem Cc: devel@edk2.groups.io, James Bottomley, Yao, Jiewen, Xu, Min M, Tom Lendacky, Michael Roth, Gerd Hoffmann [-- Attachment #1: Type: text/plain, Size: 5148 bytes --] On Tuesday, October 31, 2023 8:45 AM, Erdem Aktas wrote: > > On Sun, Oct 29, 2023 at 11:42 PM Sun, CepingX <cepingx.sun@intel.com<mailto:cepingx.sun@intel.com>> > wrote: > > > > On Saturday, October 28, 2023 12:45 AM, Erdem Aktas wrote: > > This should be the [PATCH V1 2/2] I assume? > > Yes, the name is same with [PATCH v1 0/2] , may be confusion, I would > update in next version to avoid the same title name. > > > > > > On Thu, Oct 26, 2023 at 5:58 PM sunceping <cepingx.sun@intel.com<mailto:cepingx.sun@intel.com>> wrote: > > [Sources] > > VirtualMemory.h > > MemoryEncryption.c > > + X64/TdVmCallMapGPA.nasm > > I do not think we need another TdVmCallMapGPA definition, do we? > > Currently, the TdVmCall always clears the R11 if the return code is not > successful, which means we need to change TdVmCall if we don't add > TdVmCallMapGPA. > > Refer the GHCI Spec , if the returns code is not successful, the R11 > > value is not valid for the sub-functions except MapGPA, which means > TdVmCall should clear the value on unsuccessful returns and only save the > value if MapGPA returns unsuccessfully. If an update is required, the logic in > TdVmCall could be complex. > > It seems like TdVmCallMapGPA function is actually duplicating most of the > code that the TdVmCall function is already doing. > According to the spec, R11 has meaningful data when mapgpa has RETRY, > GPA_IN_USE or ALIGN_ERROR. > I do not think the TdVmCall change logic would be complex (or not more than > what TdVmCallMapGPA is already doing). > I would like to see what others are saying on this. @Erdem Aktas<mailto:erdemaktas@google.com> In v2 Patch, use the updated TdVmcall to instead of the TdVmCallMapGPA.nasm . The v2 path mail( [PATCH V2 0/2] OvmfPkg: Update TdVmCall to handle the retry for MapGPA) has been sent , please review it. > > > > [LibraryClasses] > > BaseLib > > diff --git a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c > > b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c > > index b47f56b391a5..1f29f9194c30 100644 > > --- a/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c > > +++ b/OvmfPkg/Library/BaseMemEncryptTdxLib/MemoryEncryption.c > > @@ -38,6 +38,10 @@ typedef enum { > > > > STATIC PAGE_TABLE_POOL *mPageTablePool = NULL; > > > > +#define TDVMCALL_STATUS_RETRY 0x1 > > + > > +#define MAX_RETRIES_PER_PAGE 3 > > + > > /** > > This function is used to help request the host VMM to map a GPA range > as > > private or shared-memory mappings. > > @@ -546,6 +550,13 @@ SetOrClearSharedBit ( > > EFI_STATUS Status; > > EDKII_MEMORY_ACCEPT_PROTOCOL *MemoryAcceptProtocol; > > > > + UINT64 MapGpaRetryaddr; > > Should be replaced with MapGpaRetryAddr for consistency in variable > name casing style ? > > Yes, it would be updated in next version. > > > > + UINT32 RetryCount; > > + UINT64 EndAddress; > > + > > + MapGpaRetryaddr = 0; > > + RetryCount = 0; > > + > > AddressEncMask = GetMemEncryptionAddressMask (); > > > > // > > @@ -559,7 +570,30 @@ SetOrClearSharedBit ( > > PhysicalAddress &= ~AddressEncMask; > > } > > > > - TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, > > 0, NULL); > > + while (RetryCount < MAX_RETRIES_PER_PAGE) { > > + TdStatus = TdVmCallMapGPA (PhysicalAddress, Length, > > + &MapGpaRetryaddr); > > Why not this? > > TdStatus = TdVmCall (TDVMCALL_MAPGPA, PhysicalAddress, Length, 0, 0, > > &MapGpaRetryaddr); The TdVmCall always clears the R11 value when > unsuccessful returns as above comments, therefor add the > TdVmCallMapGPA to handle it. > right, the tdvmcall does not handle the R11 correctly for mapGPA. I think it > should be an easy fix in that function instead of creating a whole copy of that > function. > Is there a reason why we think it is complicated? > > > > > + if (TdStatus != TDVMCALL_STATUS_RETRY) { > > + break; > > + } > > + > > + DEBUG ((DEBUG_VERBOSE, "%a: TdVmcall(MAPGPA) Retry > > + PhysicalAddress is %llx, MapGpaRetryaddr is %llx\n", __func__, > > + PhysicalAddress, MapGpaRetryaddr)); > > + > > + EndAddress = PhysicalAddress + Length; > > + if ((MapGpaRetryaddr < PhysicalAddress) || (MapGpaRetryaddr > > > + EndAddress)) { > > should be? > > if ((MapGpaRetryaddr < PhysicalAddress) || (MapGpaRetryaddr >= > > EndAddress)) Yes, that’s right, it would be updated in next version. > > > > Thanks > > Ceping > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110508): https://edk2.groups.io/g/devel/message/110508 Mute This Topic: https://groups.io/mt/102212640/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=- [-- Attachment #2: Type: text/html, Size: 11826 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2023-11-02 9:25 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-10-27 0:57 [edk2-devel] [PATCH V1 0/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA sunceping 2023-10-27 0:57 ` [edk2-devel] [PATCH V1 1/2] OvmfPkg/BaseMemEncryptTdxLib: Add TdVmCallMapGPA sunceping 2023-10-27 0:57 ` [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA sunceping 2023-10-27 11:04 ` Gerd Hoffmann 2023-10-30 2:26 ` sunceping 2023-10-27 16:44 ` Erdem Aktas via groups.io 2023-10-30 6:41 ` sunceping 2023-10-31 0:45 ` Erdem Aktas via groups.io 2023-10-31 7:46 ` sunceping 2023-11-02 9:25 ` sunceping
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox