From: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-hyperv@vger.kernel.org, stefan.bader@canonical.com,
tim.gardner@canonical.com, roxana.nicolescu@canonical.com,
cascardo@canonical.com, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, sashal@kernel.org,
stable@vger.kernel.org, linux-kernel@vger.kernel.org,
"H. Peter Anvin" <hpa@zytor.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Ingo Molnar <mingo@redhat.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Michael Kelley <mhkelley58@gmail.com>,
Nikolay Borisov <nik.borisov@suse.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Tom Lendacky <thomas.lendacky@amd.com>,
x86@kernel.org, Dexuan Cui <decui@microsoft.com>
Subject: Re: [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early TDX init
Date: Wed, 22 Nov 2023 18:19:20 +0100 [thread overview]
Message-ID: <0799b692-4b26-4e00-9cec-fdc4c929ea58@linux.microsoft.com> (raw)
In-Reply-To: <20231122170106.270266-1-jpiotrowski@linux.microsoft.com>
On 22/11/2023 18:01, Jeremi Piotrowski wrote:
> Check for additional CPUID bits to identify TDX guests running with Trust
> Domain (TD) partitioning enabled. TD partitioning is like nested virtualization
> inside the Trust Domain so there is a L1 TD VM(M) and there can be L2 TD VM(s).
>
> In this arrangement we are not guaranteed that the TDX_CPUID_LEAF_ID is visible
> to Linux running as an L2 TD VM. This is because a majority of TDX facilities
> are controlled by the L1 VMM and the L2 TDX guest needs to use TD partitioning
> aware mechanisms for what's left. So currently such guests do not have
> X86_FEATURE_TDX_GUEST set.
>
> We want the kernel to have X86_FEATURE_TDX_GUEST set for all TDX guests so we
> need to check these additional CPUID bits, but we skip further initialization
> in the function as we aren't guaranteed access to TDX module calls.
>
> Cc: <stable@vger.kernel.org> # v6.5+
> Signed-off-by: Jeremi Piotrowski <jpiotrowski@linux.microsoft.com>
> ---
> arch/x86/coco/tdx/tdx.c | 29 ++++++++++++++++++++++++++---
> arch/x86/include/asm/tdx.h | 3 +++
> 2 files changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
> index 1d6b863c42b0..c7bbbaaf654d 100644
> --- a/arch/x86/coco/tdx/tdx.c
> +++ b/arch/x86/coco/tdx/tdx.c
> @@ -8,6 +8,7 @@
> #include <linux/export.h>
> #include <linux/io.h>
> #include <asm/coco.h>
> +#include <asm/hyperv-tlfs.h>
> #include <asm/tdx.h>
> #include <asm/vmx.h>
> #include <asm/insn.h>
> @@ -37,6 +38,8 @@
>
> #define TDREPORT_SUBTYPE_0 0
>
> +bool tdx_partitioning_active;
> +
> /* Called from __tdx_hypercall() for unrecoverable failure */
> noinstr void __tdx_hypercall_failed(void)
> {
> @@ -757,19 +760,38 @@ static bool tdx_enc_status_change_finish(unsigned long vaddr, int numpages,
> return true;
> }
>
> +
> +static bool early_is_hv_tdx_partitioning(void)
> +{
> + u32 eax, ebx, ecx, edx;
> + cpuid(HYPERV_CPUID_ISOLATION_CONFIG, &eax, &ebx, &ecx, &edx);
> + return eax & HV_PARAVISOR_PRESENT &&
> + (ebx & HV_ISOLATION_TYPE) == HV_ISOLATION_TYPE_TDX;
> +}
> +
> void __init tdx_early_init(void)
> {
> u64 cc_mask;
> u32 eax, sig[3];
>
> cpuid_count(TDX_CPUID_LEAF_ID, 0, &eax, &sig[0], &sig[2], &sig[1]);
> -
> - if (memcmp(TDX_IDENT, sig, sizeof(sig)))
> - return;
> + if (memcmp(TDX_IDENT, sig, sizeof(sig))) {
> + tdx_partitioning_active = early_is_hv_tdx_partitioning();
> + if (!tdx_partitioning_active)
> + return;
> + }
Hi Borislav,
Just wanted to run another option by you. Instead of checking the CPUID here we
could accomplish the same result by doing _this_ in the hyperv cc init:
diff --git a/arch/x86/hyperv/ivm.c b/arch/x86/hyperv/ivm.c
index 8c6bf07f7d2b..705794642d34 100644
--- a/arch/x86/hyperv/ivm.c
+++ b/arch/x86/hyperv/ivm.c
@@ -595,6 +595,8 @@ void __init hv_vtom_init(void)
#endif
case HV_ISOLATION_TYPE_TDX:
+ setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
+ tdx_partitioning_active = true;
cc_vendor = CC_VENDOR_INTEL;
break;
Which approach do you prefer?
Thanks,
Jeremi
>
> setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
>
> cc_vendor = CC_VENDOR_INTEL;
> +
> + /*
> + * Need to defer cc_mask and page visibility callback initializations
> + * to a TD-partitioning aware implementation.
> + */
> + if (tdx_partitioning_active)
> + goto exit;
> +
> tdx_parse_tdinfo(&cc_mask);
> cc_set_mask(cc_mask);
>
> @@ -820,5 +842,6 @@ void __init tdx_early_init(void)
> */
> x86_cpuinit.parallel_bringup = false;
>
> +exit:
> pr_info("Guest detected\n");
> }
> diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
> index 603e6d1e9d4a..fe22f8675859 100644
> --- a/arch/x86/include/asm/tdx.h
> +++ b/arch/x86/include/asm/tdx.h
> @@ -52,6 +52,7 @@ bool tdx_early_handle_ve(struct pt_regs *regs);
>
> int tdx_mcall_get_report0(u8 *reportdata, u8 *tdreport);
>
> +extern bool tdx_partitioning_active;
> #else
>
> static inline void tdx_early_init(void) { };
> @@ -71,6 +72,8 @@ static inline long tdx_kvm_hypercall(unsigned int nr, unsigned long p1,
> {
> return -ENODEV;
> }
> +
> +#define tdx_partitioning_active false
> #endif /* CONFIG_INTEL_TDX_GUEST && CONFIG_KVM_GUEST */
> #endif /* !__ASSEMBLY__ */
> #endif /* _ASM_X86_TDX_H */
next prev parent reply other threads:[~2023-11-22 17:19 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-22 17:01 [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early TDX init Jeremi Piotrowski
2023-11-22 17:01 ` [PATCH v1 2/3] x86/coco: Disable TDX module calls when TD partitioning is active Jeremi Piotrowski
2023-11-23 14:13 ` Kirill A. Shutemov
2023-11-24 10:38 ` Jeremi Piotrowski
2023-11-29 10:37 ` Huang, Kai
2023-12-01 15:27 ` Jeremi Piotrowski
2023-11-22 17:01 ` [PATCH v1 3/3] x86/tdx: Provide stub tdx_accept_memory() for non-TDX configs Jeremi Piotrowski
2023-11-23 14:11 ` Kirill A. Shutemov
2023-11-24 10:00 ` Jeremi Piotrowski
2023-11-22 17:19 ` Jeremi Piotrowski [this message]
2023-11-29 16:40 ` [PATCH v1 1/3] x86/tdx: Check for TDX partitioning during early TDX init Borislav Petkov
2023-11-30 7:08 ` Reshetova, Elena
2023-11-30 7:55 ` Borislav Petkov
2023-11-30 8:31 ` Reshetova, Elena
2023-11-30 9:21 ` Borislav Petkov
2023-12-04 16:44 ` Jeremi Piotrowski
2023-12-04 13:39 ` Jeremi Piotrowski
2023-12-04 19:37 ` Jeremi Piotrowski
2023-11-23 13:58 ` Kirill A. Shutemov
2023-11-24 10:31 ` Jeremi Piotrowski
2023-11-24 10:43 ` Kirill A. Shutemov
2023-11-24 11:04 ` Jeremi Piotrowski
2023-11-24 13:33 ` Kirill A. Shutemov
2023-11-24 16:19 ` Jeremi Piotrowski
2023-11-29 4:36 ` Huang, Kai
2023-12-01 16:16 ` Jeremi Piotrowski
2023-12-05 13:26 ` Huang, Kai
2023-12-06 18:47 ` Jeremi Piotrowski
2023-12-07 12:58 ` Huang, Kai
2023-12-07 17:21 ` Jeremi Piotrowski
2023-12-07 19:35 ` Jeremi Piotrowski
2023-12-08 10:51 ` Huang, Kai
2023-12-07 17:36 ` Reshetova, Elena
2023-12-08 12:45 ` Jeremi Piotrowski
2023-12-04 9:17 ` Reshetova, Elena
2023-12-04 19:07 ` Jeremi Piotrowski
2023-12-05 10:54 ` Kirill A. Shutemov
2023-12-06 17:49 ` Jeremi Piotrowski
2023-12-06 22:54 ` Kirill A. Shutemov
2023-12-07 17:06 ` Jeremi Piotrowski
2023-12-07 20:56 ` Kirill A. Shutemov
2023-12-05 13:24 ` Reshetova, Elena
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=0799b692-4b26-4e00-9cec-fdc4c929ea58@linux.microsoft.com \
--to=jpiotrowski@linux.microsoft.com \
--cc=bp@alien8.de \
--cc=cascardo@canonical.com \
--cc=dave.hansen@linux.intel.com \
--cc=decui@microsoft.com \
--cc=haiyangz@microsoft.com \
--cc=hpa@zytor.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=kys@microsoft.com \
--cc=linux-hyperv@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhkelley58@gmail.com \
--cc=mingo@redhat.com \
--cc=nik.borisov@suse.com \
--cc=peterz@infradead.org \
--cc=roxana.nicolescu@canonical.com \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=stefan.bader@canonical.com \
--cc=tglx@linutronix.de \
--cc=thomas.lendacky@amd.com \
--cc=tim.gardner@canonical.com \
--cc=wei.liu@kernel.org \
--cc=x86@kernel.org \
/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.