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

[Sean Christopherson <seanjc@google.com>]

On Thu, Sep 10, 2026, Xiaoyao Li wrote:
> 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.

Ya.
 
> > 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.

Eh, I'm with Xiaoyao.  Yeah, *ideally* we'd magically enable everything everywhere
all at once.  In reality, different VM types are going to support features at
different times.  More importantly, as Xiaoyao points out below in #1, unless we
enable everyting in a single patch, which is probably a terrible idea in most cases,
we'll still end up with staged/progressive enabling, i.e. we still need to have
patches that selectively enable and advertise a feature only for the VM types
that actually support the feature.

This is all quite similar to Intel and AMD feature enabling being done at different
times.  The biggest difference is that Intel and AMD are mutually exclusive and
so KVM_GET_SUPPORTED_CPUID always reports the correct information, but TDX already
provides KVM_TDX_CAPABILITIES, so AFAICT we still get accurate reporting for TDX,
just in a slightly different way.

> 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.

Yep.  If there are actual decisions to be made, versus simply adhering to the
architecture, then we'll need to incorporate the needs/abilities of flavors of
VMs KVM supports.  But for feature virtualization where right vs. wrong is
dictated by hardware specs, there really isn't anything we can do in KVM to affect
the guest-visible behavior (beyond things like performance characteristics, but
those aren't ABI in any case).

> 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.