From nobody Thu Apr 2 09:28:59 2026 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C8DFC1DFDA1 for ; Wed, 4 Mar 2026 18:10:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.16 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772647821; cv=none; b=ByRBx4eK/MAlxfNWAzSa4Fi3sOyTk0cFcqNV0PLDf3AypBgJOYn4+YTBzaYF1Zx/f+uth1a6Rq5MLdJ0q4W7H9AHmvbOSRGXftIwLnWyoY7HFZQo2AtnSXBn6xydVx5gbi+jOzoUnXbTGiYRSwR/sUjxlcUVulEZyvdo1ID+w7k= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772647821; c=relaxed/simple; bh=exuc3onWODU2X8mH2YxfaCArA6WgnFzmGL5JATuLwGc=; h=Subject:To:Cc:From:Date:References:In-Reply-To:Message-Id; b=OS3ZceXzJ3/Roc+g8nur41qNS1y5m+q7fdNiGW1PmWxK8UUYlye2rY6JRVrsrSe7ORItjFP5wLRwyYoG4o0pfoCQQEPOi605JxKti8bbLn/b0Il2MDK8ukUifpYi3qFfV678lbwIzT61nuPiVHwmXt8GO5VgFXLjPdLiQtmHxrE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=eTq6UDil; arc=none smtp.client-ip=192.198.163.16 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="eTq6UDil" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772647819; x=1804183819; h=subject:to:cc:from:date:references:in-reply-to: message-id; bh=exuc3onWODU2X8mH2YxfaCArA6WgnFzmGL5JATuLwGc=; b=eTq6UDilQc0L2nhiXdJSD8pvansNf4OPwCdWbffjVxBKaJJSzwi2GbgO rWUMAdGLDfY4jfh0M4fAbS6igMxqRqAXz/3eilYBVOrXhXfe9NLZdcCb+ hBgxLrSktCV+EfRtbf07C/MV8H+L8q65LwJdMlcPhzpFLJPhtn9sL30un rGbNrkGg5okvRsF8w3CxAys20yZOAxDb6RCteDvXXgezK6S87GbXrfRrp 9gw/vSqEf7wasrm0czSDfskcoYRB09Kit+bMlTpLJls8SbohpZ8Ngdi8R bz6xu68kmv9Xt3cH6+I0FbAGF14eUlwt6C6XceWTfGyB/qDkqfIik13v+ w==; X-CSE-ConnectionGUID: l3G5tn7TTkuZrQqeHTN8vA== X-CSE-MsgGUID: UfRcr8oBRXiQw1Ed9MJX5Q== X-IronPort-AV: E=McAfee;i="6800,10657,11719"; a="61291094" X-IronPort-AV: E=Sophos;i="6.21,324,1763452800"; d="scan'208";a="61291094" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa110.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2026 10:10:19 -0800 X-CSE-ConnectionGUID: YHIXi7uXQpGaANgLQyUtvg== X-CSE-MsgGUID: 6rlgpTTgSdeGvOAZx4hRQw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,324,1763452800"; d="scan'208";a="215752580" Received: from davehans-spike.ostc.intel.com (HELO localhost.localdomain) ([10.165.164.11]) by fmviesa010.fm.intel.com with ESMTP; 04 Mar 2026 10:10:19 -0800 Subject: [PATCH v4 1/4] x86/microcode: Refactor platform ID enumeration into a helper To: linux-kernel@vger.kernel.org Cc: sohil.mehta@intel.com, zhao1.liu@intel.com, Dave Hansen , Borislav Petkov , "H. Peter Anvin" , Ingo Molnar , Jon Kohler , Pawan Gupta , "Peter Zijlstra (Intel)" , Thomas Gleixner , Tony Luck , x86@kernel.org From: Dave Hansen Date: Wed, 04 Mar 2026 10:10:18 -0800 References: <20260304181016.85EC87C7@davehans-spike.ostc.intel.com> In-Reply-To: <20260304181016.85EC87C7@davehans-spike.ostc.intel.com> Message-Id: <20260304181018.EB6404F8@davehans-spike.ostc.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Dave Hansen Today, the only code that cares about the platform ID is the microcode update code itself. To facilitate storing the platform ID in a more generic place and using it outside of the microcode update itself, put the enumeration into a helper function. Mirror intel_get_microcode_revision()'s naming and location. But, moving away from intel_collect_cpu_info() means that the model and family information in CPUID is not readily available. Just call CPUID again. Note that the microcode header is a mask of supported platform IDs. Only stick the ID part in the helper. Leave the 1<=3DPII, say <=3DPII. The PII is the real oddball here being the only CPU with Linux microcode updates but no platform ID. It's worth calling it out by name. This does subtly change the sig->pf for the PII though from 0x0 to 0x1. Make up for that by ignoring sig->pf when the microcode update platform mask is 0x0. Signed-off-by: Dave Hansen Reviewed-by: Sohil Mehta Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: "H. Peter Anvin" Cc: Tony Luck Cc: Pawan Gupta Cc: "Peter Zijlstra (Intel)" Cc: x86@kernel.org Cc: Jon Kohler -- Changes from v3: * Handle the empty platform mask on the PII Reviewed-by: Pawan Gupta --- b/arch/x86/kernel/cpu/microcode/intel.c | 53 +++++++++++++++++++++++++--= ----- 1 file changed, 42 insertions(+), 11 deletions(-) diff -puN arch/x86/kernel/cpu/microcode/intel.c~refactor-get-processor-flag= s arch/x86/kernel/cpu/microcode/intel.c --- a/arch/x86/kernel/cpu/microcode/intel.c~refactor-get-processor-flags 20= 26-03-04 09:19:02.438748485 -0800 +++ b/arch/x86/kernel/cpu/microcode/intel.c 2026-03-04 09:19:02.441748599 -= 0800 @@ -120,19 +120,43 @@ static inline unsigned int exttable_size return et->count * EXT_SIGNATURE_SIZE + EXT_HEADER_SIZE; } =20 +/* + * Use CPUID to generate a "vfm" value. Useful + * before 'cpuinfo_x86' structures are populated. + */ +static u32 intel_cpuid_vfm(void) +{ + u32 eax =3D cpuid_eax(1); + u32 fam =3D x86_family(eax); + u32 model =3D x86_model(eax); + + return IFM(fam, model); +} + +static u32 intel_get_platform_id(void) +{ + unsigned int val[2]; + + /* + * This can be called early. Use CPUID directly instead of + * relying on cpuinfo_x86 which may not be fully initialized. + * The PII does not have MSR_IA32_PLATFORM_ID. Everything + * before _it_ has no microcode (for Linux at least). + */ + if (intel_cpuid_vfm() <=3D INTEL_PENTIUM_II_KLAMATH) + return 0; + + /* get processor flags from MSR 0x17 */ + native_rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]); + + return (val[1] >> 18) & 7; +} + void intel_collect_cpu_info(struct cpu_signature *sig) { sig->sig =3D cpuid_eax(1); - sig->pf =3D 0; sig->rev =3D intel_get_microcode_revision(); - - if (IFM(x86_family(sig->sig), x86_model(sig->sig)) >=3D INTEL_PENTIUM_III= _DESCHUTES) { - unsigned int val[2]; - - /* get processor flags from MSR 0x17 */ - native_rdmsr(MSR_IA32_PLATFORM_ID, val[0], val[1]); - sig->pf =3D 1 << ((val[1] >> 18) & 7); - } + sig->pf =3D 1 << intel_get_platform_id(); } EXPORT_SYMBOL_GPL(intel_collect_cpu_info); =20 @@ -142,8 +166,15 @@ static inline bool cpu_signatures_match( if (s1->sig !=3D sig2) return false; =20 - /* Processor flags are either both 0 or they intersect. */ - return ((!s1->pf && !pf2) || (s1->pf & pf2)); + /* + * Consider an empty mask to match everything. This + * should only occur for one CPU model, the PII. + */ + if (!pf2) + return true; + + /* Is the CPU's platform ID in the signature mask? */ + return s1->pf & pf2; } =20 bool intel_find_matching_signature(void *mc, struct cpu_signature *sig) _