From: Nikolay Borisov <nik.borisov@suse.com>
To: Kai Huang <kai.huang@intel.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: x86@kernel.org, dave.hansen@intel.com,
kirill.shutemov@linux.intel.com, peterz@infradead.org,
tony.luck@intel.com, tglx@linutronix.de, bp@alien8.de,
mingo@redhat.com, hpa@zytor.com, seanjc@google.com,
pbonzini@redhat.com, rafael@kernel.org, david@redhat.com,
dan.j.williams@intel.com, len.brown@intel.com,
ak@linux.intel.com, isaku.yamahata@intel.com,
ying.huang@intel.com, chao.gao@intel.com,
sathyanarayanan.kuppuswamy@linux.intel.com, bagasdotme@gmail.com,
sagis@google.com, imammedo@redhat.com
Subject: Re: [PATCH v14 07/23] x86/virt/tdx: Add skeleton to enable TDX on demand
Date: Wed, 18 Oct 2023 12:14:44 +0300 [thread overview]
Message-ID: <4a8b6084-bd4b-46cf-b0b1-396684e7a7b3@suse.com> (raw)
In-Reply-To: <4fd10771907ae276548140cf7f8746e2eb38821c.1697532085.git.kai.huang@intel.com>
On 17.10.23 г. 13:14 ч., Kai Huang wrote:
> To enable TDX the kernel needs to initialize TDX from two perspectives:
> 1) Do a set of SEAMCALLs to initialize the TDX module to make it ready
> to create and run TDX guests; 2) Do the per-cpu initialization SEAMCALL
> on one logical cpu before the kernel wants to make any other SEAMCALLs
> on that cpu (including those involved during module initialization and
> running TDX guests).
>
> The TDX module can be initialized only once in its lifetime. Instead
> of always initializing it at boot time, this implementation chooses an
> "on demand" approach to initialize TDX until there is a real need (e.g
> when requested by KVM). This approach has below pros:
>
> 1) It avoids consuming the memory that must be allocated by kernel and
> given to the TDX module as metadata (~1/256th of the TDX-usable memory),
> and also saves the CPU cycles of initializing the TDX module (and the
> metadata) when TDX is not used at all.
>
> 2) The TDX module design allows it to be updated while the system is
> running. The update procedure shares quite a few steps with this "on
> demand" initialization mechanism. The hope is that much of "on demand"
> mechanism can be shared with a future "update" mechanism. A boot-time
> TDX module implementation would not be able to share much code with the
> update mechanism.
>
> 3) Making SEAMCALL requires VMX to be enabled. Currently, only the KVM
> code mucks with VMX enabling. If the TDX module were to be initialized
> separately from KVM (like at boot), the boot code would need to be
> taught how to muck with VMX enabling and KVM would need to be taught how
> to cope with that. Making KVM itself responsible for TDX initialization
> lets the rest of the kernel stay blissfully unaware of VMX.
>
> Similar to module initialization, also make the per-cpu initialization
> "on demand" as it also depends on VMX being enabled.
>
> Add two functions, tdx_enable() and tdx_cpu_enable(), to enable the TDX
> module and enable TDX on local cpu respectively. For now tdx_enable()
> is a placeholder. The TODO list will be pared down as functionality is
> added.
>
> Export both tdx_cpu_enable() and tdx_enable() for KVM use.
>
> In tdx_enable() use a state machine protected by mutex to make sure the
> initialization will only be done once, as tdx_enable() can be called
> multiple times (i.e. KVM module can be reloaded) and may be called
> concurrently by other kernel components in the future.
>
> The per-cpu initialization on each cpu can only be done once during the
> module's life time. Use a per-cpu variable to track its status to make
> sure it is only done once in tdx_cpu_enable().
>
> Also, a SEAMCALL to do TDX module global initialization must be done
> once on any logical cpu before any per-cpu initialization SEAMCALL. Do
> it inside tdx_cpu_enable() too (if hasn't been done).
>
> tdx_enable() can potentially invoke SEAMCALLs on any online cpus. The
> per-cpu initialization must be done before those SEAMCALLs are invoked
> on some cpu. To keep things simple, in tdx_cpu_enable(), always do the
> per-cpu initialization regardless of whether the TDX module has been
> initialized or not. And in tdx_enable(), don't call tdx_cpu_enable()
> but assume the caller has disabled CPU hotplug, done VMXON and
> tdx_cpu_enable() on all online cpus before calling tdx_enable().
>
> Signed-off-by: Kai Huang <kai.huang@intel.com>
> Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
With the latest explanation from Kai :
Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
next prev parent reply other threads:[~2023-10-18 9:14 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-17 10:14 [PATCH v14 00/23] TDX host kernel support Kai Huang
2023-10-17 10:14 ` [PATCH v14 01/23] x86/virt/tdx: Detect TDX during kernel boot Kai Huang
2023-10-17 13:24 ` Kuppuswamy Sathyanarayanan
2023-10-17 10:14 ` [PATCH v14 02/23] x86/tdx: Define TDX supported page sizes as macros Kai Huang
2023-10-17 10:14 ` [PATCH v14 03/23] x86/virt/tdx: Make INTEL_TDX_HOST depend on X86_X2APIC Kai Huang
2023-10-17 10:14 ` [PATCH v14 04/23] x86/cpu: Detect TDX partial write machine check erratum Kai Huang
2023-10-17 10:14 ` [PATCH v14 05/23] x86/virt/tdx: Handle SEAMCALL no entropy error in common code Kai Huang
2023-10-17 13:34 ` Kuppuswamy Sathyanarayanan
2023-10-17 10:14 ` [PATCH v14 06/23] x86/virt/tdx: Add SEAMCALL error printing for module initialization Kai Huang
2023-10-17 13:37 ` Kuppuswamy Sathyanarayanan
2023-10-18 6:27 ` Huang, Kai
2023-10-18 7:40 ` Nikolay Borisov
2023-10-18 8:26 ` Huang, Kai
2023-10-18 14:17 ` Kuppuswamy Sathyanarayanan
2023-10-17 10:14 ` [PATCH v14 07/23] x86/virt/tdx: Add skeleton to enable TDX on demand Kai Huang
2023-10-17 14:24 ` Kuppuswamy Sathyanarayanan
2023-10-18 6:51 ` Huang, Kai
2023-10-18 13:56 ` Dave Hansen
2023-10-18 19:55 ` Huang, Kai
2023-10-18 7:57 ` Nikolay Borisov
2023-10-18 8:29 ` Huang, Kai
2023-10-18 8:39 ` Nikolay Borisov
2023-10-18 8:57 ` Huang, Kai
2023-10-18 9:14 ` Nikolay Borisov [this message]
2023-10-18 9:17 ` Huang, Kai
2023-10-17 10:14 ` [PATCH v14 08/23] x86/virt/tdx: Get information about TDX module and TDX-capable memory Kai Huang
2023-10-17 10:14 ` [PATCH v14 09/23] x86/virt/tdx: Use all system memory when initializing TDX module as TDX memory Kai Huang
2023-10-17 10:14 ` [PATCH v14 10/23] x86/virt/tdx: Add placeholder to construct TDMRs to cover all TDX memory regions Kai Huang
2023-10-17 10:14 ` [PATCH v14 11/23] x86/virt/tdx: Fill out " Kai Huang
2023-10-17 10:14 ` [PATCH v14 12/23] x86/virt/tdx: Allocate and set up PAMTs for TDMRs Kai Huang
2023-10-24 5:53 ` Nikolay Borisov
2023-10-24 10:49 ` Huang, Kai
2023-10-24 13:31 ` Nikolay Borisov
2023-10-17 10:14 ` [PATCH v14 13/23] x86/virt/tdx: Designate reserved areas for all TDMRs Kai Huang
2023-10-17 10:14 ` [PATCH v14 14/23] x86/virt/tdx: Configure TDX module with the TDMRs and global KeyID Kai Huang
2023-10-17 10:14 ` [PATCH v14 15/23] x86/virt/tdx: Configure global KeyID on all packages Kai Huang
2023-10-17 10:14 ` [PATCH v14 16/23] x86/virt/tdx: Initialize all TDMRs Kai Huang
2023-10-17 10:14 ` [PATCH v14 17/23] x86/kexec: Flush cache of TDX private memory Kai Huang
2023-10-17 10:14 ` [PATCH v14 18/23] x86/virt/tdx: Keep TDMRs when module initialization is successful Kai Huang
2023-10-17 10:14 ` [PATCH v14 19/23] x86/virt/tdx: Improve readability of module initialization error handling Kai Huang
2023-10-17 10:14 ` [PATCH v14 20/23] x86/kexec(): Reset TDX private memory on platforms with TDX erratum Kai Huang
2023-10-17 10:14 ` [PATCH v14 21/23] x86/virt/tdx: Handle TDX interaction with ACPI S3 and deeper states Kai Huang
2023-10-17 10:53 ` Rafael J. Wysocki
2023-10-18 3:22 ` Huang, Kai
2023-10-18 10:15 ` Rafael J. Wysocki
2023-10-18 10:51 ` Huang, Kai
2023-10-18 10:53 ` Rafael J. Wysocki
2023-10-19 20:45 ` Huang, Kai
2023-10-24 10:46 ` Huang, Kai
2023-10-17 10:14 ` [PATCH v14 22/23] x86/mce: Improve error log of kernel space TDX #MC due to erratum Kai Huang
2023-10-17 10:14 ` [PATCH v14 23/23] Documentation/x86: Add documentation for TDX host support Kai Huang
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=4a8b6084-bd4b-46cf-b0b1-396684e7a7b3@suse.com \
--to=nik.borisov@suse.com \
--cc=ak@linux.intel.com \
--cc=bagasdotme@gmail.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=david@redhat.com \
--cc=hpa@zytor.com \
--cc=imammedo@redhat.com \
--cc=isaku.yamahata@intel.com \
--cc=kai.huang@intel.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=sagis@google.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=ying.huang@intel.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 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).