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

[Binbin Wu]

On 9/3/2026 12:25 AM, Binbin Wu wrote:
> On 9/3/2026 12:22 AM, Edgecombe, Rick P wrote:
>> On Thu, 2026-09-03 at 00:19 +0800, Binbin Wu wrote:
>>>> I see. You added patch 2 because without it QEMU breaks. While for
>>>> EST/TM2/SDBG/XTPR/DCA, QEMU doesn't break after they are turned to
>>>> non-configurable. QEMU cannot represent all the userspace VMM. It still has
>>>> the potential to breaks other userspace VMMs.
>>>
>>> I think the risk is pretty low.
>>> I am not sure if Sean could provide some insight about this in google's
>>> userspace VMM.
>>
>> Can't we fix the issue if we are wrong?
> 
> I think it could be fixed to add the missing bits (if any) as bug fix.

Directly configurable feature bits that KVM doesn't support for non-TDX VMs
fall into five categories:

1) Features that are forced to 0 when #VE is reduced, or they lack KVM's
   support for associated MSRs:
   EST, TM2, SDBG, DCA, ACPI, ACC (TM), RDT_A, RDT_M, TME, PCONFIG.

2) Features tied to MSR_IA32_MISC_ENABLE, whose corresponding
   IA32_MISC_ENABLE bit can't be set from a TD's point of view when
   TDCS.TD_CTLS.REDUCE_VE is set:
   CID, PBE.

3) Host state clobbering features that KVM doesn't support for TDX:
   HLE, RTM, WAITPKG, FRED.

Features in categories 1-3 should not be added to the allow list.

4) Features that are simply unsupported and thus don't need to be in the
   allow list:
   PREFETCHWT1 (Xeon Phi only), PSN (not implemented by TDX-capable
   CPUs), AMX-TRANSPOSE (never implemented on any Intel platform), and
   RAO_INT (defined only for "future processors").

5) Features that are added to the allow list via TDX_CFG_EXTRA_F():
   MWAIT, XTPR, HT, CORE_CAPABILITIES.

   XTPR can be exposed to a TD, but it never takes effect in the
   underlying hardware when the guest changes IA32_MISC_ENABLE[23].

   CORE_CAPABILITIES really belongs to category 1, but it's special
   because older specs defined it as a fixed-1 bit, so userspace VMMs
   may try to enable it based on stale knowledge.  Add it to the allow
   list to accommodate the legacy TDX module definition.  Reporting
   CORE_CAPABILITIES as directly configurable also lets userspace infer
   that the bit is no longer fixed-1, and correct its stale knowledge.
   Keep MSR_IA32_CORE_CAPS unsupported for TDX guests because existing
   TDX users have no guest access to MSR_IA32_CORE_CAPS.

With the features in category 5 in the allow list, it shouldn't break
userspace.

If no objection, the next version will still limit the allow list to the
capabilities KVM supported for non-TDX VMs, with a few exceptions listed
in category 5.