All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Binbin Wu <binbin.wu@linux.intel.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	pbonzini@redhat.com,  rick.p.edgecombe@intel.com,
	xiaoyao.li@intel.com, chao.gao@intel.com,  kai.huang@intel.com
Subject: Re: [RFC PATCH v2 1/4] KVM: x86: TDX: Track supported configurable CPUID bits
Date: Thu, 25 Jun 2026 10:04:11 -0700	[thread overview]
Message-ID: <aj1fi_0SBxMK5WOB@google.com> (raw)
In-Reply-To: <20260604023314.3907511-2-binbin.wu@linux.intel.com>

On Thu, Jun 04, 2026, Binbin Wu wrote:
> ---
>  arch/x86/kvm/vmx/tdx.c | 174 +++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 174 insertions(+)
> 
> diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
> index ffe9d0db58c5..e0567088ebf5 100644
> --- a/arch/x86/kvm/vmx/tdx.c
> +++ b/arch/x86/kvm/vmx/tdx.c
> @@ -52,6 +52,178 @@
>  	__TDX_BUG_ON(__err, #__fn, __kvm, ", " #a1 " 0x%llx, " #a2 ", 0x%llx, " #a3 " 0x%llx", \
>  		     a1, a2, a3)
>  
> +#define TDX_CPUID_IGNORE_INDEX	BIT(0)
> +struct tdx_supported_cpuid_reg {
> +	u32 function;
> +	u32 index;
> +	u8 flags;
> +	u8 reg;
> +	u32 mask;
> +};
> +
> +/*
> + * Multi-bit fields are statically initialized, feature bits are initialized
> + * in tdx_initialize_cpu_cfg_caps().
> + */
> +static struct tdx_supported_cpuid_reg tdx_kvm_supported_cpuid[] __ro_after_init = {
> +	{ 0x1, 0, 0, CPUID_EAX, GENMASK_U32(27, 16) | GENMASK_U32(13, 0) },
> +	{ 0x1, 0, 0, CPUID_EBX, GENMASK_U32(23, 16) },
> +	{ 0x1, 0, 0, CPUID_ECX, 0 },
> +	{ 0x1, 0, 0, CPUID_EDX, 0 },
> +	{ 0x4, 0, TDX_CPUID_IGNORE_INDEX, CPUID_EAX, ~GENMASK_U32(13, 10) },
> +	{ 0x4, 0, TDX_CPUID_IGNORE_INDEX, CPUID_EBX, GENMASK_U32(31, 12) },
> +	{ 0x4, 0, TDX_CPUID_IGNORE_INDEX, CPUID_ECX, GENMASK_U32(31, 0) },
> +	{ 0x4, 0, TDX_CPUID_IGNORE_INDEX, CPUID_EDX, GENMASK_U32(2, 0) },
> +	{ 0x7, 0, 0, CPUID_EBX, 0 },
> +	{ 0x7, 0, 0, CPUID_ECX, 0 },
> +	{ 0x7, 0, 0, CPUID_EDX, 0 },
> +	{ 0x7, 1, 0, CPUID_EAX, 0 },
> +	{ 0x7, 1, 0, CPUID_EDX, 0 },
> +	{ 0x7, 2, 0, CPUID_EDX, 0 },
> +	{ 0x18, 0, TDX_CPUID_IGNORE_INDEX, CPUID_EDX, GENMASK_U32(25, 14) },
> +	{ 0x1E, 1, 0, CPUID_EAX, 0 },
> +	{ 0x1F, 0, TDX_CPUID_IGNORE_INDEX, CPUID_EAX, GENMASK_U32(4, 0) },
> +	{ 0x1F, 0, TDX_CPUID_IGNORE_INDEX, CPUID_EBX, GENMASK_U32(15, 0) },
> +	{ 0x1F, 0, TDX_CPUID_IGNORE_INDEX, CPUID_ECX, GENMASK_U32(15, 0) },
> +	/* See comments in td_init_cpuid_entry2() for CPUID 0x80000008 EAX[23:16]. */
> +	{ 0x80000008, 0, 0, CPUID_EAX, GENMASK_U32(23, 16) | GENMASK_U32(7, 0) },
> +	{ 0x80000008, 0, 0, CPUID_EBX, 0 },

For non-feature bits, I think I would rather handle them entirely at runtime via
switch statement(s).  Realistically, CPUID.0x1.E{A,B}X are never going to be
repurposed to hold feature bits, and so generating a mask of allowed bits adds
unnecessary cognitive load and maintenance.  Ditto for CPUID 0x4, 0x18, and 0x1F.

CPUID.0x1E is a bit different because it's kinda sorta a feature?  That one is
probably worth restricting, but again that's easy to do in a case-statement.

Then for the feature bits, there should be no need to define a separate structure,
just do "u32 kvm_tdx_cpu_caps[NR_KVM_CPU_CAPS]".  Then KVM can even further
restrict that array with kvm_cpu_caps (though it might take some creativity to
deal with things like MWAIT).  Because generally speaking, KVM shouldn't allow
features that KVM doesn't support for non-TDX VMs.

  parent reply	other threads:[~2026-06-25 17:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-04  2:33 [RFC PATCH v2 0/4] KVM: x86: TDX: Validate directly configurable CPUID bits Binbin Wu
2026-06-04  2:33 ` [RFC PATCH v2 1/4] KVM: x86: TDX: Track supported " Binbin Wu
2026-06-04  2:44   ` sashiko-bot
2026-06-04  5:37     ` Binbin Wu
2026-06-25 17:04   ` Sean Christopherson [this message]
2026-06-04  2:33 ` [RFC PATCH v2 2/4] KVM: x86: TDX: Hide unsupported " Binbin Wu
2026-06-04  2:47   ` sashiko-bot
2026-06-04  2:54     ` Binbin Wu
2026-06-04  2:33 ` [RFC PATCH v2 3/4] KVM: x86: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM Binbin Wu
2026-06-04  2:49   ` sashiko-bot
2026-06-04  3:13     ` Binbin Wu
2026-06-04  2:33 ` [RFC PATCH v2 4/4] KVM: x86: TDX: Report CORE_CAPABILITIES as supported Binbin Wu
2026-06-04  2:51   ` sashiko-bot
2026-06-04  5:32     ` Binbin Wu
2026-06-04  5:40       ` Binbin Wu
2026-06-04  6:53   ` Xiaoyao Li
2026-06-04  7:20     ` Binbin Wu
2026-06-22  6:32 ` [RFC PATCH v2 0/4] KVM: x86: TDX: Validate directly configurable CPUID bits Binbin Wu
2026-06-25 17:04   ` Sean Christopherson

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=aj1fi_0SBxMK5WOB@google.com \
    --to=seanjc@google.com \
    --cc=binbin.wu@linux.intel.com \
    --cc=chao.gao@intel.com \
    --cc=kai.huang@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=rick.p.edgecombe@intel.com \
    --cc=xiaoyao.li@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 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.