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.
