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

[Xiaoyao Li <xiaoyao.li@intel.com>]

On 9/9/2026 5:13 AM, Edgecombe, Rick P wrote:
>>>> 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.

I don't think "split lock detection" is a good example. We are discussing
virtualizing a feature, or allowing a feature to be exposed to non-TDX and TDX
guests. While "split lock detection" is not a virtualizable feature and how KVM
handles it is all about how KVM fixes the architectural flaw of it.

Generally, I agree with your point that we need to think at higher level before
KVM deciding to support virtualizing a feature. But after the generic level
consideration is done, there can be different orders:

1. allow a feature for non-TDX VMs and TDs at same time. i.e., in one patch or
in a single series.

2. allow a feature for non-TDX VMs first and then TDs. This can be due to by
that time TDX's spec for the feature has not been defined/finalized.

3. allow a feature for TDs first and then non-TDX VMs. This can be due to it
requires more effort/patches to support virtualizing a feature for non-TDX VMs.

Usually allowing a feature for TDs requires far less efforts than for non-TDX
VMs, because most of the virtualization work is done by TDX module. E.g., for
TDs, KVM usually only needs to add code to restore the host states that are not
restored by TDX module. However for non-TDX VMs, KVM needs to do more: emulate
the architectural behavior of the MSRs, context switch states, and the nested
handling, etc. It's likely that a series to enable a feature for non-TDX VMs
spends several Linux releases to finally get merged. Making TDX support depends
on it seems not that necessary.