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

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

On Tue, 2025-08-19 at 10:38 +0300, Adrian Hunter wrote:
> On 18/08/2025 21:49, 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.
> 
> That would not help with existing TDX Modules, and would possibly require
> a guest opt-in, which would not help with existing guests.  Hence, to start
> with disabling the feature first, and look for another solution second.

I think you have the priorities wrong. There are only so many kludges we can ask
KVM to take. Across all the changes people want for TDX, do you think not having
to update the TDX module, backport a guest fix or even just adjust qemu args is
more important the other stuff?

TDX support is still very early. We need to think about long term sustainable
solutions. So a fix that doesn't support existing TDX modules or guests (the
intel_idle fix is also in this category anyway) should absolutely be on the
table.

> 
> In the MWAIT case, Sean has rejected supporting MSR_PKG_CST_CONFIG_CONTROL
> even for VMX, because it is an optional MSR, so altering intel_idle is
> being proposed.

It seems reasonable for this specific case.

> 
> > 
> > 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)
> 
> It is still "new stuff that breaks old stuff" which is generally
> "just don't do that".
> 

I don't think so? It doesn't necessarily break old stuff if userspace doesn't
use the bit yet.