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

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

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.

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.