Re: [PATCH v3 1/4] KVM: TDX: Track configurable CPUID bits allowed by KVM

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Thu, 2026-09-03 at 15:28 +0800, Xiaoyao Li wrote:
> > In this version, TDX_CFG_F() already check against kvm_cpu_caps[], if these
> > features
> > are not in kvm_cpu_caps[], it will not be exposed to userspace anyway.
> > 
> 
> I still think the reasoning that we omit them because they are not
> contained in kvm_cpu_caps[] sounds not right. Based on it, so when we are
> going to add a new feature for TDX, we need to first manually check the KVM
> code to see if that feature is contained in kvm_cpu_caps[] already. If not,
> we just don't add it to TDX's list. Then why need to cap the result
> kvm_cpu_caps[] for TDX_CFG_F() again? Just for safety in case human make
> mistake and misread the code of kvm_cpu_caps[]?

We could warn on the condition and not just silently strip it.

> 
> I think they are two independent steps:
> 1. list the CPUID features that KVM can support for TDs.
> 2. apply additional restrictions, e.g., if a feature is not allowed for
> non-TDX VMs, it cannot be allowed for TDs.
> 
> > > In the end, they might be disallowed to be configured to TDs because KVM
> > > doesn't allow them for VMX VMs. This is also the point I want to discuss.
> > > Do we really want to make such restriction that KVM cannot enable/allow a
> > > feature for TDs unless KVM first enables/allows it for VMX VMs? What's
> > > reason behind it?
> > Sean mentioned it that "generally speaking, KVM shouldn't allow features
> > that KVM doesn't support for non-TDX VMs" in
> > https://lore.kernel.org/kvm/aj1fi_0SBxMK5WOB@google.com/
> 
> For existing features, it might make some sense. But for new features, I
> don't think so. It defines the enabling order for new features that we must
> enable a feature for non-TDX VMs first and then TDs. And people might want
> to bypass this rule by abusing the TDX_CFG_EXTRA_F() when only one line of
> TDX_CFG_EXTRA_F() is enough to enable a feature for TDs but more effort
> required to enable it for non-TDX VMs.
> 
> Maybe I miss somthing. I would like to see stronger reasons for such decision.

I think "generally speaking" means, it's not a hard rule.

As for why to prefer it, I think we would normally want regulars VMs and TDs to
work similarly. Especially those that have some of the virtualization handled by
KVM. But TDX module's behavior of a feature can conform to KVM's only if KVM's
already exists. Take for example split lock detection. The normal VM KVM support
initially went through several iterations of design. Separately, TDX ended up
with a different solution. Imagine if we had enabled the TDX arch one, before
solving the general KVM problems. Then we would end up with two different
behaviors, or a worse KVM behavior as it tries to conform to TDX module's
behavior.

So we need to at least solve a feature at that level before deciding KVM's
handling of it. This could be done while enabling the feature for TDX only, but
often would involve solving the problems for normal VMs too. In the end, it's
the generic KVM behavior that needs to be solved before enabling the feature.

Ideally we could consider normal VM and TD at the same time. I expect we will
start doing that after this series is in place. Not a hard rule, but a norm.