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

[Binbin Wu]

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.