Re: [PATCH RFC 1/2] KVM: TDX: Disable general support for MWAIT in guest

[Binbin Wu <binbin.wu@linux.intel.com>]

On 8/19/2025 2:49 AM, Edgecombe, Rick P wrote:
> Attn: Binbin, Xiaoyao
>
> On Mon, 2025-08-18 at 07:05 -0700, Sean Christopherson wrote:
>> NAK.
>>
>> Fix the guest, or wherever else in the pile there are issues.  KVM is NOT carrying
>> hack-a-fixes to workaround buggy software/firmware.  Been there, done that.
> Yes, I would have thought we should have at least had a TDX module change option
> for this.
>
> But side topic. We have an existing arch TODO around creating some guidelines
> around how CPUID bit configuration should evolve.
>
> A new directly configurable CPUID bit that affects host state is an obvious no-
> no. But how about a directly configurable bit that can't hurt the host, but
> requires host changes to virtualize in an x86 arch compliant way? (not quite
> like this MWAIT case)
>
> In some ways KVM shouldn't care since it's between userspace and the TDX module.
> But userspace may try to set it and then we would have a situation where the bit
> would remain malfunctioning until/if KVM decided to add support for the bit. If
> KVM never did then it would be silently broken. It's not a kernel regression,
> but not great either.
>
> If we required some other opt-in for each such feature, it would further
> complicate the CPUID bit configuration interface. I think I'd rather keep
> directly configurable CPUID bits as the main way to configure the TD.

Currently, KVM TDX code filters out TSX (HLE or RTM) and WAITPKG using
tdx_clear_unsupported_cpuid(), which is sort of blacklist.

I am wondering if we could add another array, e.g., tdx_cpu_caps[], which is the
TDX version of kvm_cpu_caps[].

Using tdx_cpu_caps[] is a whitelist way.
For a new feature
- If the developer doesn't know anything about TDX, the bit just be added to
   kvm_cpu_caps[].
- If the developer knows that the feature supported by both non-TDX VMs and TDs
   (either the feature doesn't require any additional virtualization support or
   the virtualization support is added for TDX), extend the macros to set the bit
   both in kvm_cpu_caps[] and tdx_cpu_caps[].
- If there is a feature not supported by non-TDX VMs, but supported by TDs,
   extend the macros to set the bit only in tdx_cpu_caps[].
So, tdx_cpu_caps[] could be used as the filter of configurable bits reported
to userspace.

Comparing to blacklist (i.e., tdx_clear_unsupported_cpuid()), there is no risk
that a feature not supported by TDX is forgotten to be added to the blacklist.
Also, tdx_cpu_caps[] could support a feature that not supported for non-TDX VMs.

Then we don't need a host opt-in for these directly configurable bits not
clobbering host states.

Of course, to prevent userspace from setting feature bit that would clobber host
state, but not included in tdx_cpu_caps[], I think a new feature that would
clobber host state should requires a host opt-in to TDX module.

>
> Maybe we could have the TDX module enumerate which direct bits require VMM
> enabling and KVM could automatically filter them? So then TDX module could add
> simple feature bits without fuss, but KVM could manually enable the bits that
> require consideration.