linux-coco.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: "Huang, Kai" <kai.huang@intel.com>
To: "kirill.shutemov@linux.intel.com"
	<kirill.shutemov@linux.intel.com>,
	"Miao, Jun" <jun.miao@intel.com>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>
Cc: "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>
Subject: Re: [PATCH] x86/virt/tdx: accurately distinguishes TDX module loading situations
Date: Fri, 19 Jul 2024 01:31:06 +0000	[thread overview]
Message-ID: <0d36d5a74669b75b238181b99805ec6e232b39b9.camel@intel.com> (raw)
In-Reply-To: <20240622175037.2051612-1-jun.miao@intel.com>

On Sun, 2024-06-23 at 01:50 +0800, Jun Miao wrote:
> The first SEAMCALL is important to response the state of TDX Module/BIOS.
> 
> In actual incorrect BIOS setup or deployment, the sysinit_ret will be
> -EOPNOTSUPP. But the message "module not loaded" isn`t enough to describe
> the accurate loading situation when module loaded but SEAMCALL failed
> for some BIOS wrong setting. So add the error return operation code number.

(firstly, please CC me in the future, and please also CC x86 maintainers,
x86@kernel.org, and linux-kernel@vger.kernel.org). 

So this is the case where TDX is detected as enabled by the kernel (TDX KeyID
reports valid info), but TDX actually isn't enabled by the BIOS.

This seems BIOS bug to me.  The BIOS should never report valid TDX KeyID if TDX
isn't enabled.  I guess it happens on development machines, but I am not sure
whether the production machine would fix this.

Anyway ...

> 
> Signed-off-by: Jun Miao <jun.miao@intel.com>
> ---
>  arch/x86/virt/vmx/tdx/tdx.c | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
> index 4e2b2e2ac9f9..787dfaf44036 100644
> --- a/arch/x86/virt/vmx/tdx/tdx.c
> +++ b/arch/x86/virt/vmx/tdx/tdx.c
> @@ -122,10 +122,14 @@ static int try_init_module_global(void)
>  	/*
>  	 * The first SEAMCALL also detects the TDX module, thus
>  	 * it can fail due to the TDX module is not loaded.
> -	 * Dump message to let the user know.
> +	 * Dump more detailed message to let the user know.
>  	 */
>  	if (sysinit_ret == -ENODEV)
>  		pr_err("module not loaded\n");
> +	else if (sysinit_ret)
> +		pr_warn("module loaded error ret=%d\n",sysinit_ret);
> +	else
> +		pr_info("module loaded\n");
>  
>  	sysinit_done = true;
>  out:

... printing the error code won't help user a lot since it is not obvious to the
user.  I think we can do something below.

Hi Dave/Kirill,

Any comments?

diff --git a/arch/x86/virt/vmx/tdx/tdx.c b/arch/x86/virt/vmx/tdx/tdx.c
index 49a1c6890b55..a8c273cfe17e 100644
--- a/arch/x86/virt/vmx/tdx/tdx.c
+++ b/arch/x86/virt/vmx/tdx/tdx.c
@@ -119,13 +119,35 @@ static int try_init_module_global(void)
        args.rcx = 0;
        sysinit_ret = seamcall_prerr(TDH_SYS_INIT, &args);
 
-       /*
-        * The first SEAMCALL also detects the TDX module, thus
-        * it can fail due to the TDX module is not loaded.
-        * Dump message to let the user know.
-        */
-       if (sysinit_ret == -ENODEV)
+       switch (sysinit_ret) {
+       case -ENODEV:
+               /*
+                * The first SEAMCALL also detects the TDX module,
+                * thus it can fail due to the TDX module is not
+                * loaded.  Dump message to let the user know.
+                */
                pr_err("module not loaded\n");
+               break;
+       case -EOPNOTSUPP:
+               /*
+                * Some TDX-capable development machines may report
+                * valid TDX KeyID when TDX is actually not enabled
+                * by the BIOS (e.g., due to BIOS misconfiguration).
+                * Let the user know.
+                */
+               pr_err("[BIOS bug]: TDX isn't enabled.\n");
+               break;
+       case -EACCES:
+               /*
+                * -EACCES happens when this is called when CPU is
+                * not in post-VMXON state.  It's kernel issue, so
+                * don't dump error message.
+                */
+               break;
+       default:
+               /* Actual SEAMCALL failure, message already printed */
+               break;
+       }
 
        sysinit_done = true;
 out:



      parent reply	other threads:[~2024-07-19  1:31 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-22 17:50 [PATCH] x86/virt/tdx: accurately distinguishes TDX module loading situations Jun Miao
2024-06-24 11:26 ` Kirill A. Shutemov
2024-06-28 17:17   ` Jun Miao
2024-07-19  1:31 ` Huang, Kai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0d36d5a74669b75b238181b99805ec6e232b39b9.camel@intel.com \
    --to=kai.huang@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=jun.miao@intel.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-coco@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).