From: Chao Gao <chao.gao@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: <linux-kernel@vger.kernel.org>, <kvm@vger.kernel.org>,
<kai.huang@intel.com>
Subject: Re: [PATCH 3/3] KVM: VMX: Initialize TDX during KVM module load
Date: Thu, 28 Nov 2024 11:00:45 +0800 [thread overview]
Message-ID: <Z0fc3Z6YJB20uP3G@intel.com> (raw)
In-Reply-To: <20241127201019.136086-4-pbonzini@redhat.com>
>+static void __do_tdx_cleanup(void)
>+{
>+ /*
>+ * Once TDX module is initialized, it cannot be disabled and
>+ * re-initialized again w/o runtime update (which isn't
>+ * supported by kernel). Only need to remove the cpuhp here.
>+ * The TDX host core code tracks TDX status and can handle
>+ * 'multiple enabling' scenario.
>+ */
>+ WARN_ON_ONCE(!tdx_cpuhp_state);
>+ cpuhp_remove_state_nocalls(tdx_cpuhp_state);
...
>+static int __init __do_tdx_bringup(void)
>+{
>+ int r;
>+
>+ /*
>+ * TDX-specific cpuhp callback to call tdx_cpu_enable() on all
>+ * online CPUs before calling tdx_enable(), and on any new
>+ * going-online CPU to make sure it is ready for TDX guest.
>+ */
>+ r = cpuhp_setup_state_cpuslocked(CPUHP_AP_ONLINE_DYN,
>+ "kvm/cpu/tdx:online",
>+ tdx_online_cpu, NULL);
>+ if (r < 0)
>+ return r;
>+
>+ tdx_cpuhp_state = r;
>+
>+ r = tdx_enable();
>+ if (r)
>+ __do_tdx_cleanup();
The self deadlock issue isn't addressed.
>+
>+ return r;
>+}
>+
>+static bool __init kvm_can_support_tdx(void)
>+{
>+ return cpu_feature_enabled(X86_FEATURE_TDX_HOST_PLATFORM);
...
>+int __init tdx_bringup(void)
>+{
>+ int r;
>+
>+ if (!enable_tdx)
>+ return 0;
>+
>+ if (!kvm_can_support_tdx()) {
>+ pr_err("tdx: no TDX private KeyIDs available\n");
The lack of X86_FEATURE_TDX_HOST_PLATFORM doesn't necessarily mean no TDX
private KeyIDs. In tdx_init(), X86_FEATURE_TDX_HOST_PLATFORM is not set if
hibernation is enabled.
>+ goto success_disable_tdx;
>+ }
>+
>+ if (!enable_virt_at_load) {
>+ pr_err("tdx: tdx requires kvm.enable_virt_at_load=1\n");
>+ goto success_disable_tdx;
>+ }
>+
>+ /*
>+ * Ideally KVM should probe whether TDX module has been loaded
>+ * first and then try to bring it up. But TDX needs to use SEAMCALL
>+ * to probe whether the module is loaded (there is no CPUID or MSR
>+ * for that), and making SEAMCALL requires enabling virtualization
>+ * first, just like the rest steps of bringing up TDX module.
>+ *
>+ * So, for simplicity do everything in __tdx_bringup(); the first
>+ * SEAMCALL will return -ENODEV when the module is not loaded. The
>+ * only complication is having to make sure that initialization
>+ * SEAMCALLs don't return TDX_SEAMCALL_VMFAILINVALID in other
>+ * cases.
>+ */
>+ r = __tdx_bringup();
>+ if (r) {
>+ /*
>+ * Disable TDX only but don't fail to load module if
>+ * the TDX module could not be loaded. No need to print
>+ * message saying "module is not loaded" because it was
>+ * printed when the first SEAMCALL failed.
>+ */
>+ if (r == -ENODEV)
>+ goto success_disable_tdx;
Given that two error messages are added above, I think it is worth adding one
more here for consistency. And, reloading KVM will not trigger the "module is
not loaded" error which is printed once.
>+
>+ enable_tdx = 0;
>+ }
>+
>+ return r;
>+
>+success_disable_tdx:
>+ enable_tdx = 0;
>+ return 0;
>+}
next prev parent reply other threads:[~2024-11-28 3:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-27 20:10 [PATCH v3 0/3] KVM: VMX: Initialize TDX during KVM module load Paolo Bonzini
2024-11-27 20:10 ` [PATCH 1/3] KVM: Export hardware virtualization enabling/disabling functions Paolo Bonzini
2024-11-27 20:10 ` [PATCH 2/3] KVM: VMX: Refactor VMX module init/exit functions Paolo Bonzini
2024-11-27 20:10 ` [PATCH 3/3] KVM: VMX: Initialize TDX during KVM module load Paolo Bonzini
2024-11-28 3:00 ` Chao Gao [this message]
2024-11-28 3:04 ` Huang, Kai
2024-11-28 3:34 ` Huang, Kai
-- strict thread matches above, loose matches on Subject: below --
2024-10-28 13:20 [PATCH 0/3] KVM: VMX: Initialize TDX when loading KVM module Kai Huang
2024-10-28 13:20 ` [PATCH 3/3] KVM: VMX: Initialize TDX during KVM module load Kai Huang
2024-10-30 15:19 ` Sean Christopherson
2024-10-31 11:17 ` Huang, Kai
2024-10-31 20:22 ` Sean Christopherson
2024-10-31 21:21 ` Huang, Kai
2024-10-31 21:29 ` Edgecombe, Rick P
2024-11-06 14:19 ` Edgecombe, Rick P
2024-11-06 10:49 ` Huang, Kai
2024-11-06 15:01 ` Sean Christopherson
2024-11-06 20:06 ` Huang, Kai
2024-11-07 22:04 ` Sean Christopherson
2024-11-07 23:25 ` Huang, Kai
2024-10-31 21:52 ` Dan Williams
2024-10-31 22:37 ` Huang, Kai
2024-10-31 22:56 ` Dan Williams
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=Z0fc3Z6YJB20uP3G@intel.com \
--to=chao.gao@intel.com \
--cc=kai.huang@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.