Re: [PATCH v5 06/12] x86/tdx: Get TD execution environment information via TDINFO

From: Kuppuswamy, Sathyanarayanan
Date: Fri Aug 20 2021 - 13:31:18 EST




On 8/20/21 10:13 AM, Borislav Petkov wrote:
On Wed, Aug 04, 2021 at 11:13:23AM -0700, Kuppuswamy Sathyanarayanan wrote:
From: "Kirill A. Shutemov" <kirill.shutemov@xxxxxxxxxxxxxxx>

Per Guest-Host-Communication Interface (GHCI) for Intel Trust
Domain Extensions (Intel TDX) specification, sec 2.4.2,
TDCALL[TDINFO] provides basic TD execution environment information, not
provided by CPUID.

Call TDINFO during early boot to be used for following system
initialization.

The call provides info on which bit in pfn is used to indicate that the
page is shared with the host and attributes of the TD, such as debug.

Information about the number of CPUs need not be saved because there are
no users so far for it.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx>
Reviewed-by: Andi Kleen <ak@xxxxxxxxxxxxxxx>
Reviewed-by: Tony Luck <tony.luck@xxxxxxxxx>
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@xxxxxxxxxxxxxxx>
---

Changes since v4:
* None

Changes since v3:
* None

arch/x86/kernel/tdx.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)

diff --git a/arch/x86/kernel/tdx.c b/arch/x86/kernel/tdx.c
index 287564990f21..3973e81751ba 100644
--- a/arch/x86/kernel/tdx.c
+++ b/arch/x86/kernel/tdx.c
@@ -8,6 +8,14 @@
#include <asm/tdx.h>
+/* TDX Module call Leaf IDs */
+#define TDINFO 1
+
+static struct {
+ unsigned int gpa_width;
+ unsigned long attributes;
+} td_info __ro_after_init;

Where is that thing even used? I don't see it in the whole patchset.

It is used in different patch set. If you prefer to move it there, I can
move it to that patch set.

patch: https://lore.kernel.org/patchwork/patch/1472343/
series: https://lore.kernel.org/patchwork/project/lkml/list/?series=510836



+
/*
* Wrapper for standard use of __tdx_hypercall with BUG_ON() check
* for TDCALL error.
@@ -54,6 +62,19 @@ bool tdx_prot_guest_has(unsigned long flag)
}
EXPORT_SYMBOL_GPL(tdx_prot_guest_has);
+static void tdg_get_info(void)

Also, what Sean said: "tdx_" please. Unless there's a real reason to
have a different prefix - then state that reason.

+{
+ u64 ret;
+ struct tdx_module_output out = {0};

The tip-tree preferred ordering of variable declarations at the
beginning of a function is reverse fir tree order::

struct long_struct_name *descriptive_name;
unsigned long foo, bar;
unsigned int tmp;
int ret;

The above is faster to parse than the reverse ordering::

int ret;
unsigned int tmp;
unsigned long foo, bar;
struct long_struct_name *descriptive_name;

And even more so than random ordering::

unsigned long foo, bar;
int ret;
struct long_struct_name *descriptive_name;
unsigned int tmp;

I will re-check the TDX patchset and fix the ordering issues.


+
+ ret = __tdx_module_call(TDINFO, 0, 0, 0, 0, &out);
+
+ BUG_ON(ret);

WARNING: Avoid crashing the kernel - try using WARN_ON & recovery code rather than BUG() or BUG_ON()
#121: FILE: arch/x86/kernel/tdx.c:72:
+ BUG_ON(ret);

I have already fixed reasonable check-patch issues. For this case, we
want to use BUG_ON(). Failure in tdx_module_call means buggy TDX
module. So it is safer to crash the kernel.


Have I already told you about checkpatch?

If not, here it is:

Please integrate scripts/checkpatch.pl into your patch creation
workflow. Some of the warnings/errors *actually* make sense.


--
Sathyanarayanan Kuppuswamy
Linux Kernel Developer