Re: [PATCH v2] KVM: x86: Remove AMX-TF32 enumeration

["Chang S. Bae" <chang.seok.bae@intel.com>]

On 7/23/2026 11:04 AM, Sean Christopherson wrote:
> 
> I'm not convinced that yanking out support is the right move.  By publishing the
> feature, for several years, Intel pretty much burned that CPUID bit.  E.g. it's
> not impossible that someone other than Intel has implemented TF32 instructions.
> 
> The opcodes are fair game in the future, because their use can be qualified and
> guarded, but the same doesn't hold true for enumeration.  E.g. similar to how
> MPX got ripped out and its XSTATE assets got reused for APX, but the CPUID feature
> enumeration is forever reserved for MPX (I hope).
> 
> If the argument is that "Intel Architecture Instruction Set Extensions and Future
> Features" isn't binding documentation, i.e. that Intel can do take backs until a
> feature is documented in the SDM, then I honestly don't see any option but to
> refuse to accept new features until they land in the SDM.  Which I don't think
> any of us want.
One distinction I could think of is whether a feature ever ships in 
implementations. If a feature is actually implemented and is later 
deprecated or removed, then I agree the bit should remain reserved. That 
appears quite clear.

My understanding is that the revert was considered because TF32 never 
reached any implementation. If that's incorrect, I'd certainly welcome a 
correction. But if it holds true, then I also want to clarify the case 
is different from retiring a feature that was already in products.

That said though, I think you made a point. If new features are 
published there, we add support based on that, and are later asked to 
remove the support, it becomes harder to convince what level of 
stability the ISE doc can provide.

I don't think these decisions are made lightly. We humans may sometimes 
reconsider features before they ever ship. But cases like this 
inevitably damage the credibility. If this happens repeatedly, it 
becomes increasingly reasonable to take a more conservative approach -- 
perhaps even until there is hardware implementation at hand.

I'd relay this feedback to the relevant folks, as I do think this is an 
important point to consider. I'll cc you.

Thanks,
Chang