Received-SPF: pass (google.com: domain of linux-kernel+bounces-123339-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Thu, 28 Mar 2024 18:06:08 +0100
From: Borislav Petkov <bp@alien8.de>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: "x86@kernel.org" <x86@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 01/74] x86/cpu/vfm: Add/initialize x86_vfm field to
 struct cpuinfo_x86
Message-ID: <20240328170608.GFZgWjgGSqFL7kGQkE@fat_crate.local>
References: <20240328163746.243023-1-tony.luck@intel.com>
 <20240328163746.243023-2-tony.luck@intel.com>
 <20240328164811.GDZgWfSzAWZXO7dUky@fat_crate.local>
 <SJ1PR11MB60836FBDB2ADF1B3B8A02EFFFC3B2@SJ1PR11MB6083.namprd11.prod.outlook.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <SJ1PR11MB60836FBDB2ADF1B3B8A02EFFFC3B2@SJ1PR11MB6083.namprd11.prod.outlook.com>

On Thu, Mar 28, 2024 at 04:56:37PM +0000, Luck, Tony wrote:
> I could make the raw format of the #define values be CPUID(1).EAX
> with the stepping masked out. But then I'd need to add a new field to
> the structure instead of overlaying with the vendor/family/model
> fields.

Yes, that would be better. And if you're going to replace our f/m/s
checking with something better, then it better handle the stepping just
like the rest. How it is used now doesn't mean a whole lot for the
future.

And if it is not too important for most checks, you can mask it out with
macros.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette