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

[Sean Christopherson <seanjc@google.com>]

On Tue, Feb 24, 2026, Rick P Edgecombe wrote:
> 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.

To stable@?  No, I don't think see any reason to do that.

> 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?

Sure, I don't see a rush on the patch.

> 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,

Maybe I'm missing something, but I think you're reading into the WARN waaaay too
much.  I suggested it purely as a paranoid guard against the TDX Module doing
something bizarre and/or the kernel fat-fingering a CPUID function.  I.e. there's
no ulterior motive here, unless maybe Changyuan is planning world domination or
something. :-D

> 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.