Re: [PATCH v5 4/5] KVM: TDX: Report only KVM-allowed CPUIDs in KVM_TDX_CAPABILITIES

[Xiaoyao Li]

On 10/22/2026 10:20 AM, Binbin Wu wrote:
> On 10/22/2026 1:19 AM, Edgecombe, Rick P wrote:
>> On Wed, 2026-10-21 at 10:15 +0800, Binbin Wu wrote:
>>> On 10/21/2026 8:39 AM, Edgecombe, Rick P wrote:
>>>> On Fri, 2026-10-16 at 17:14 +0800, Binbin Wu wrote:
>>>>> Note, the change is user-visible, as some bits that were previously
>>>>> reported as configurable no longer are.  The ABI itself is unchanged: KVM
>>>>> already filtered unsupported CPUID bits out of KVM_TDX_CAPABILITIES, albeit
>>>>> via a denylist, and the set of configurable bits already varies with the
>>>>> TDX module and KVM versions.
>>>>
>>>> I'm not sure what this is saying, the change is user visible but there is no ABI
>>>> change? Can't be both... so I think there is an ABI change.
>>>
>>> My understanding is KVM_TDX_CAPABILITIES reports the capabilities supported by
>>> the TDX module *and* KVM, this is not changed before and after this patch series.
>>> ABI-wise, I think userspace doesn't care how KVM do the filter, denylist-based or
>>> allowlist-based. The ABI requires userspace to consult KVM_TDX_CAPABILITIES, and
>>> what KVM_TDX_CAPABILITIES report can be changed. That's why I described the ABI
>>> itself didn't change.
>>
>> My model is that ABI is the user visible behavior of the kernel. So if you are
>> running a kernel on a machine, and upgrade the kernel, then the behavior changes
>> for your (potentially misguided) userspace. That is still an ABI change.
>>
>> I think you are thinking about it like a spec - that if the new behavior
>> conforms to the spec, it is not an ABI change. I think it's not right.
>>
>>>
>>> How about simply noting that this is a user-visible change and dropping the ABI
>>> part to avoid any ambiguity about the scope of the ABI?
>>
>> Eh, if you want. I'm ok as long as we don't declare there is no ABI change. And
>> then the patch ends up breaking userspace with a log saying no ABI change
>> because of the docs. It could come off wrong.
>>
>> We are making a potentially breaking change here that we think won't impact any
>> users. It's a sensitive thing.
> 
> Rick sent me a link about the discussions on "what ABI is".
> https://lore.kernel.org/lkml/alpine.LFD.2.00.0812011210030.3256@xxxxxxxxxxxxxxxxxxxxxxxxxxxx/
> 
> I will rephrase it in the next version as following:
> 
> Note, this is an ABI change, as some bits that were previously reported as
> configurable no longer are.  However, the semantics of
> KVM_TDX_CAPABILITIES are unchanged: KVM already filtered unsupported bits
> out of KVM_TDX_CAPABILITIES, albeit via a denylist, and the set of
> reported bits already varies with the TDX module and KVM versions, i.e.
> userspace can't assume a fixed set.

Reviewed-by: Xiaoyao Li <xiaoyao.li@xxxxxxxxx>