From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"binbin.wu@linux.intel.com" <binbin.wu@linux.intel.com>
Cc: "Gao, Chao" <chao.gao@intel.com>,
"seanjc@google.com" <seanjc@google.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"kas@kernel.org" <kas@kernel.org>,
"Li, Xiaoyao" <xiaoyao.li@intel.com>,
"dedekind1@gmail.com" <dedekind1@gmail.com>,
"Maloor, Kishen" <kishen.maloor@intel.com>,
"tony.lindgren@linux.intel.com" <tony.lindgren@linux.intel.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"nik.borisov@suse.com" <nik.borisov@suse.com>,
"Hunter, Adrian" <adrian.hunter@intel.com>
Subject: Re: [PATCH v5 4/5] KVM: TDX: Report only KVM-allowed CPUIDs in KVM_TDX_CAPABILITIES
Date: Wed, 21 Oct 2026 17:19:48 +0000 [thread overview]
Message-ID: <b196cf9f65fe1e52aba7b867b7c2687c40caa337.camel@intel.com> (raw)
In-Reply-To: <2bc913d2-4286-4484-a872-3266326db0a5@linux.intel.com>
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.
next prev parent reply other threads:[~2026-10-21 17:19 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 9:14 [PATCH v5 0/5] KVM: TDX: Validate directly configurable CPUID bits Binbin Wu
2026-10-16 9:14 ` [PATCH v5 1/5] KVM: TDX: Check unsupported CPUID bits against the TDX module's subleaf Binbin Wu
2026-10-16 15:25 ` Sean Christopherson
2026-10-16 22:15 ` Binbin Wu
2026-10-16 23:26 ` Sean Christopherson
2026-10-16 9:14 ` [PATCH v5 2/5] KVM: TDX: Track configurable CPUID bits allowed by KVM Binbin Wu
2026-10-16 9:14 ` [PATCH v5 3/5] KVM: TDX: Add CORE_CAPABILITIES to the allowlist Binbin Wu
2026-10-16 9:14 ` [PATCH v5 4/5] KVM: TDX: Report only KVM-allowed CPUIDs in KVM_TDX_CAPABILITIES Binbin Wu
2026-10-21 0:39 ` Edgecombe, Rick P
2026-10-21 2:15 ` Binbin Wu
2026-10-21 17:19 ` Edgecombe, Rick P [this message]
2026-10-16 9:14 ` [PATCH v5 5/5] KVM: TDX: Validate userspace CPUID input for KVM_TDX_INIT_VM Binbin Wu
2026-10-21 0:59 ` [PATCH v5 0/5] KVM: TDX: Validate directly configurable CPUID bits Edgecombe, Rick P
2026-10-21 17:43 ` Nikolay Borisov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b196cf9f65fe1e52aba7b867b7c2687c40caa337.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=adrian.hunter@intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=binbin.wu@linux.intel.com \
--cc=chao.gao@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=dedekind1@gmail.com \
--cc=kas@kernel.org \
--cc=kishen.maloor@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nik.borisov@suse.com \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=tony.lindgren@linux.intel.com \
--cc=xiaoyao.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®