[edk2-devel] [PATCH V1 0/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

[edk2-devel] [PATCH V1 0/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

[sunceping]

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]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V1 1/2] OvmfPkg/BaseMemEncryptTdxLib: Add TdVmCallMapGPA

[sunceping]

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]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

[sunceping]

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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

[Gerd Hoffmann]

  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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

[Erdem Aktas via groups.io]

[-- 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 --]

Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

[sunceping]

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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

[sunceping]

[-- 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 --]

Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

[Erdem Aktas via groups.io]

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]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

[sunceping]

[-- 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 --]

Re: [edk2-devel] [PATCH V1 2/2] OvmfPkg/BaseMemEncryptTdxLib: Handle retry result of MapGPA

[sunceping]

[-- 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 --]