Re: [RFC PATCH] x86/cpu: Change AMD uarch detection

[Sohil Mehta <sohil.mehta@intel.com>]

On 10/30/2026 6:55 PM, Borislav Petkov wrote:

> So, we're going back to the initial method because that's what this is
> - x86_uarch is the microarchitecture number I am giving it and not x86_vfm
> - a family/model/stepping tuple.
> 

Yes, that makes sense. Though, I am wondering if it would be better to
define x86_uarch outside the x86_vfm union?

With your initial patch,

	union {
		struct {
			__u8	x86_model;
			__u8	x86;
			__u8	x86_vendor;
			__u8	x86_uarch;
		};
		__u32		x86_vfm;
	};

x86_vfm is calculated as:

    uarch << 24 | vendor << 16 | family << 8 | model

However, VFM_MAKE() is defined as

#define	VFM_MAKE(_vendor, _family, _model) (	\
	((_model) << VFM_MODEL_BIT) |		\
	((_family) << VFM_FAMILY_BIT) |		\
	((_vendor) << VFM_VENDOR_BIT)		\
)

Is the thinking that we could make x86_uarch work with all the VFM
macros? Because, if they can't be used together, then placing x86_uarch
in the union x86_vfm is confusing and likely to cause mistakes.

For example, I initially thought that amd_tsa_microcode comparison might
fail, because it uses VFM_MAKE(). But, it doesn't do a direct x86_vfm
comparison so it is safe.