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

[Edgecombe, Rick P]

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.