Re: [PATCH v3 0/4] KVM: TDX: Validate directly configurable CPUID bits

[Binbin Wu]

On 9/9/2026 4:30 AM, Artem Bityutskiy wrote:
> **Disclaimer**: I am new to KVM and TDX, still learning, let me know if
> some of my comments are off.
> 
> It took me several days digging through docs and code to understand what is
> going on here,

Thanks!

[...]

> 
> CPUID_CONFIG is different: it lets userspace set CPUID leaf values
> directly (but not for any CPUID, only for pieces of it the TDX module
> allows, and KVM enumerates them via the KVM_TDX_CAPABILITIES ioctl).
> 
> That is the problematic part. KVM does not check its contents, beyond a
> denylist that only filters out TSX and WAITPKG features. Everything
> else is allowed.
> 
> So your patch-set basically kicks out the current denylist mechanism
> and replaces it with an allowlist of directly configurable CPUID leaves
> and bits.
> 

[...]

> 
> Did I understand your work correctly?

Yes, you understand it correctly.

> 
>> Expected host state clobbering behavior for TDX
>> ===============================================
>> We also want to call for discussions about the expected host state
>> clobbering behavior for TDX here for future features.
>>
>> For a normal VMX guest, VM entry/exit behavior for a given piece of CPU
>> state is architecturally defined: state is either switched by hardware via
>> VMCS host/guest fields, or left as the guest value on VM exit and managed
>> by KVM in software.
>>
>> For TDs, the host/guest transition goes through TDH.VP.ENTER, and what the
>> TDX module does with a given piece of host state is defined by the TDX
>> module ABI rather than by the x86 architecture.
> 
> I think I found this contract: the TDH.VP.ENTER definition in the ABI
> spec, section "CPU State Preservation Following a Successful TD Entry
> and a TD Exit". It refers to a table that lists the MSRs whose value
> may not be preserved across TD entry and exit, with the condition for
> each, e.g.
> 
>   IA32_PL0_SSP         Init(XFAM[11] | XFAM[12])
>   IA32_UMWAIT_CONTROL  Init(virt. CPUID(7,0).ECX[5])
> 
> This is from an older version of the TDX ABI specification. I could not
> find 'msr_preservation.pdf' published. But I assume it is published.

You can find these tables from the "Intel TDX Module ABI Definitions" part on
https://www.intel.com/content/www/us/en/developer/tools/trust-domain-extensions/documentation.html
 
[...]

> So maybe the way to go is to just follow 'msr_preservation.pdf' and
> adjust the allowlist? I find this approach safe and acceptable.
> 

Rick explained the long history:
https://lore.kernel.org/all/58c185c82658819454a9950f37c6424226a098bb.camel@xxxxxxxxx/

The Denylist based solution is not a clean solution:
- It couples the feature enabling for normal VMs with TDX tightly.
- Each time a new feature is added in the denylist, it needs to be backported to old KVM versions


> Artem.