From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.15]) (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 85914BA21 for ; Thu, 5 Mar 2026 02:26:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.15 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772677605; cv=none; b=QBObrFarygGTvn9MCAnFBmg5mwLKKP1UMiQPV5bfQSOoGTuuG+v3T1hbwDEY67q/QPoob5tCHlrrRwvgNgYltDdGzG4wyucCd8NGeTvQ1sRZRfeiudXwPPBXVq0LLVLsweZntu7xicdrkNb8xDRA5H8A+TGgg0qHZm4g08/gO58= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772677605; c=relaxed/simple; bh=Rtyo4Vc0DrjK/8DDJlI8Kuc7RbdSTaO+IsqC0bm0ujw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UOmppEoAwDUdkT5DzIsMVSjx/UWTkzOlYitKwL25x/yTI0rVLVA5haK4eyimaIZnABeQUwFlupylyyj0BLKvWsHXa6GYMOa9r1FmfmQc3I0aUZ0UUnEPY7LOThK9PRSbO/y3/97Td3ubKc/lK++znKQFSoxP3UmxrSTzsi0unnI= 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=Ui4UxKF+; arc=none smtp.client-ip=198.175.65.15 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="Ui4UxKF+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1772677603; x=1804213603; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Rtyo4Vc0DrjK/8DDJlI8Kuc7RbdSTaO+IsqC0bm0ujw=; b=Ui4UxKF+bxWvpassCmAzoftBtHZ+8POg1Lu63D1557hUC3kUakX+AY06 A3Xa9f2ogKLO/6PMODu/9TI7p+0IBOszZ5zpMWiPIYxIoDSrLq1ddiQrV 9u5/cfAH+5rGNz+fKc0mBWlHFNHHoq4KxBeVY4yaRAEmF42A9NYKFsO3U q+JSrrCBs7s6bIymoPDTY7UNkODwcRl93bjxNokFMXNL6Y3jX97zyyUtP 4f7pJd/+7JLdMduVBqIaTAeCx1HdbtRBs6leneQ5tsjF/9rtGdem65/B8 FG0WLVDb/l1CD20d7uhkOCsqTw67z/xAZFRRyvLrJMcHdf6KNRjREFVQA g==; X-CSE-ConnectionGUID: oos8hGUhQs66yZcrvGNFzA== X-CSE-MsgGUID: jGPjrsc3Tl6LoxWQEevIAw== X-IronPort-AV: E=McAfee;i="6800,10657,11719"; a="77356428" X-IronPort-AV: E=Sophos;i="6.21,325,1763452800"; d="scan'208";a="77356428" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa107.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2026 18:26:43 -0800 X-CSE-ConnectionGUID: f8nDrZ6qR0WleSQMPz75VQ== X-CSE-MsgGUID: XwsZoVcfTBObKteX9+Srpw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,325,1763452800"; d="scan'208";a="256414566" Received: from guptapa-desk.jf.intel.com (HELO desk) ([10.165.239.46]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Mar 2026 18:26:43 -0800 Date: Wed, 4 Mar 2026 18:26:36 -0800 From: Pawan Gupta To: Dave Hansen Cc: linux-kernel@vger.kernel.org, sohil.mehta@intel.com, zhao1.liu@intel.com, Borislav Petkov , "H. Peter Anvin" , Ingo Molnar , Jon Kohler , "Peter Zijlstra (Intel)" , Thomas Gleixner , Tony Luck , x86@kernel.org Subject: Re: [PATCH v4 2/4] x86/cpu: Add platform ID to CPU info structure Message-ID: <20260305022636.pt4zt42qjiudxtbz@desk> References: <20260304181016.85EC87C7@davehans-spike.ostc.intel.com> <20260304181020.8D518228@davehans-spike.ostc.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260304181020.8D518228@davehans-spike.ostc.intel.com> On Wed, Mar 04, 2026 at 10:10:20AM -0800, Dave Hansen wrote: > > From: Dave Hansen > > The end goal here is to be able to do x86_match_cpu() and match on a > specific platform ID. While it would be possible to stash this ID > off somewhere or read it dynamically, that approaches would not be > consistent with the other fields which can be matched. > > Read the platform ID and store it in cpuinfo_x86. > > There are lots of sites to set this new field. Place it near > the place c->microcode is established since the platform ID is > so closely intertwined with microcode updates. > > Note: This should not grow the size of 'struct cpuinfo_x86' in > practice since the u8 fits next to another u8 in the structure. > > 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 v2: > * rename x86_platform_id=>intel_platform_id and remove > initialization from generic code > * Add a amd_unused so it's clear the AMD folks have a > free field to play with. > --- > > b/arch/x86/include/asm/microcode.h | 2 ++ > b/arch/x86/include/asm/processor.h | 5 +++++ > b/arch/x86/kernel/cpu/intel.c | 1 + > b/arch/x86/kernel/cpu/microcode/intel.c | 2 +- > 4 files changed, 9 insertions(+), 1 deletion(-) > > diff -puN arch/x86/include/asm/microcode.h~cpu-x86_stepping arch/x86/include/asm/microcode.h > --- a/arch/x86/include/asm/microcode.h~cpu-x86_stepping 2026-02-24 15:37:21.947261472 -0800 > +++ b/arch/x86/include/asm/microcode.h 2026-02-24 15:37:21.955261858 -0800 > @@ -61,6 +61,8 @@ static inline int intel_microcode_get_da > return hdr->datasize ? : DEFAULT_UCODE_DATASIZE; > } > > +extern u32 intel_get_platform_id(void); > + > static inline u32 intel_get_microcode_revision(void) > { > u32 rev, dummy; > diff -puN arch/x86/include/asm/processor.h~cpu-x86_stepping arch/x86/include/asm/processor.h > --- a/arch/x86/include/asm/processor.h~cpu-x86_stepping 2026-02-24 15:37:21.949261568 -0800 > +++ b/arch/x86/include/asm/processor.h 2026-02-24 15:37:21.955261858 -0800 > @@ -140,6 +140,11 @@ struct cpuinfo_x86 { > __u32 x86_vfm; > }; > __u8 x86_stepping; > + union { > + // MSR_IA32_PLATFORM_ID[52-50] > + __u8 intel_platform_id; > + __u8 amd_unused; > + }; > #ifdef CONFIG_X86_64 > /* Number of 4K pages in DTLB/ITLB combined(in pages): */ > int x86_tlbsize; > diff -puN arch/x86/kernel/cpu/intel.c~cpu-x86_stepping arch/x86/kernel/cpu/intel.c > --- a/arch/x86/kernel/cpu/intel.c~cpu-x86_stepping 2026-02-24 15:37:21.950261617 -0800 > +++ b/arch/x86/kernel/cpu/intel.c 2026-02-24 15:37:21.955261858 -0800 > @@ -205,6 +205,7 @@ static void early_init_intel(struct cpui > > if (c->x86 >= 6 && !cpu_has(c, X86_FEATURE_IA64)) > c->microcode = intel_get_microcode_revision(); > + c->intel_platform_id = intel_get_platform_id(); Just want to make sure that c->intel_platform_id not getting explicitly initialized for !CONFIG_CPU_SUP_INTEL is okay. I believe it is fine because the global boot_cpu_data should be zero-initialized. I see model and stepping are being initialized in identify_cpu(), but I don't see any vendor specific initialization here: identify_cpu() { int i; c->loops_per_jiffy = loops_per_jiffy; c->x86_cache_size = 0; c->x86_vendor = X86_VENDOR_UNKNOWN; c->x86_model = c->x86_stepping = 0; /* So far unknown... */ Reviewed-by: Pawan Gupta