Re: [PATCH] KVM: TDX: Set SIGNIFCANT_INDEX flag for supported CPUIDs

From: Edgecombe, Rick P

Date: Tue Feb 24 2026 - 13:46:00 EST


On Tue, 2026-02-24 at 08:03 -0800, Sean Christopherson wrote:
> > But adding the consistency check here would cause compatibility issue.
> > Generally, if a new CPUID indexed function is added for some new CPU and
> > the TDX module reports it, KVM versions without the CPUID function in
> > the list will trigger the warning.
>
> IMO, that's a good thing and working as intended.  WARNs aren't inherently
> evil. While the goal is to be WARN-free, in this case triggering the WARN if
> the TDX Module is updated (or new silicon arrives) is desirable, because it
> alerts us to that new behavior, so that we can go update KVM.
>
> But we should "fix" 0x23 and 0x24 before landing this patch.

Would we backport those changes then? I would usually think that if the TDX
module updates in such a way that triggers a warning in the kernel then it's a
TDX module bug.

I'm still not clear on the impact of this one, but assuming it's not too
serious, could we discuss the WIP CPUID bit TDX arch stuff in PUCK before doing
the change?

We were initially focusing on the problem of CPUID bits that affect host state,
but then recently were discussing how many other categories of potential
problems we should worry about at this point. So it would be good to understand
the impact here.

If this warn is a trend towards doubling back on the initial decision to expose
the CPUID interface to userspace, which I think is still doable and worth
considering as an alternative, then this also affects how we would want the TDX
module changes to work.