From patchwork Tue Mar 11 15:02:05 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pawan Gupta X-Patchwork-Id: 872739 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (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 5E07E25DB0B; Tue, 11 Mar 2025 15:02:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741705329; cv=none; b=QjMLrBjqkRd+kfe2GDPcn/0/PBaX49uV+vP0y285vah9F9PYmY6xPgN5kqKE787xZ5nyzRwb6DITPiIo7abJT2TN1SKDiYMGcWelHw8H8qHSyeXskw/wdqAwlejmD5fA9Yrt+8snhUz/Fr5pUgFnY0WIpMJon1S8qpv8PdxG6a0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741705329; c=relaxed/simple; bh=Gw274Q7YoUgbXnVwSweOM2+zHmkdsP+cM3iaEd6DPjA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=lWvnBC52q5AFJ456YoupLl8nYqhzejs6d8LXOuKSfB4MxAec+LsldaZ11fvBFflVV5SFoX3bz6A8OwFqrsxTDrVOjIWbB3/SrW94fmr/l2iKExj4fOcBIWF1nQn4uD2znZLKmN6NjtEWGDhpGqhgqf9wpIJLPL0TB0R6CjBgw1E= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=F6JS0tpJ; arc=none smtp.client-ip=192.198.163.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none 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="F6JS0tpJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1741705327; x=1773241327; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=Gw274Q7YoUgbXnVwSweOM2+zHmkdsP+cM3iaEd6DPjA=; b=F6JS0tpJFVE2G6eYpmfZrEiwivfylX7viJBPztQz+9lqraWndgaUKKh1 tsa7uXMUsKO6cTtSDVvHruYO/z1xjehFXrdincenOwHYjhV9hRqrdLEib b9fGHYeqvkHvDZfinXp/MXGaplnFNDYlaMNNdmcf5D0ek125NzJNkEKsu 5YHTpEbTVQf6EHs+WGrC6mOXZROFbkEeJje80YldigDqN01MSuSASHDTt z20gkSDyscC6J8zU9ogG+f2GPkdWWHjUf9WxlELynML0rXu/EkUm+7trM 3lmHvJ54gws/rfIp9ZFczMcynUDKE2CXfhhynsfEKocJ5VsbElxdt0vsK g==; X-CSE-ConnectionGUID: oCMSsQS+QROpiWht8Awmig== X-CSE-MsgGUID: HNNgdYKWQFG3gOSDF89Wtw== X-IronPort-AV: E=McAfee;i="6700,10204,11370"; a="41917407" X-IronPort-AV: E=Sophos;i="6.14,239,1736841600"; d="scan'208";a="41917407" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2025 08:02:06 -0700 X-CSE-ConnectionGUID: 98SD0B52SBGEi+F7wBrf4g== X-CSE-MsgGUID: jxdD4NWJR2GWsAT06arfBg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,239,1736841600"; d="scan'208";a="125388467" Received: from ghakimel-mobl.amr.corp.intel.com (HELO desk) ([10.125.145.184]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2025 08:02:05 -0700 Date: Tue, 11 Mar 2025 08:02:05 -0700 From: Pawan Gupta To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: daniel.sneddon@linux.intel.com, tony.luck@intel.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-perf-users@vger.kernel.org, Josh Poimboeuf , Srinivas Pandruvada , "Rafael J. Wysocki" , Ricardo Neri , "Liang, Kan" , Andrew Cooper , Brice Goglin , Mario Limonciello , Perry Yuan , Dapeng Mi Subject: [PATCH v8 1/5] x86/cpu: Fix the description of X86_MATCH_VFM_STEPS() Message-ID: <20250311-add-cpu-type-v8-1-e8514dcaaff2@linux.intel.com> X-Mailer: b4 0.14.1 References: <20250311-add-cpu-type-v8-0-e8514dcaaff2@linux.intel.com> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250311-add-cpu-type-v8-0-e8514dcaaff2@linux.intel.com> The comments needs to reflect an implementation change. No functional change. Signed-off-by: Pawan Gupta --- arch/x86/include/asm/cpu_device_id.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h index ba32e0f44cba..9ebc263832ff 100644 --- a/arch/x86/include/asm/cpu_device_id.h +++ b/arch/x86/include/asm/cpu_device_id.h @@ -209,9 +209,11 @@ #define __X86_STEPPINGS(mins, maxs) GENMASK(maxs, mins) /** - * X86_MATCH_VFM_STEPPINGS - Match encoded vendor/family/model/stepping + * X86_MATCH_VFM_STEPS - Match encoded vendor/family/model and steppings + * range. * @vfm: Encoded 8-bits each for vendor, family, model - * @steppings: Bitmask of steppings to match + * @min_step: Lowest stepping number to match + * @max_step: Highest stepping number to match * @data: Driver specific data or NULL. The internal storage * format is unsigned long. The supplied value, pointer * etc. is cast to unsigned long internally. From patchwork Tue Mar 11 15:02:20 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pawan Gupta X-Patchwork-Id: 873011 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.19]) (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 9FA7925DAE8; Tue, 11 Mar 2025 15:02:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.19 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741705347; cv=none; b=ZOhyPafDXATJ8Qb2B4T4clo8lvaqjZlK1zNg615o2NzDGLKHSVfb4LRFIGmUKi3OvOsMgMdPcmuE1C/B3b/oJOo8eLHLYWM4FjL8RDKRMRqXlqFWLKGXiYBHL06b30XYeadcQSBM+MYvoegJpLQQF+02uBCFOpX/eCO6GSR3V2o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741705347; c=relaxed/simple; bh=coDGYA3G+yyYMnLYZxfS8hKebjAu/7The5gGiic6xpY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KVEOAe259Hp6fgJUkdIaCSl/R8cWbknxyTvwwTvB6N5uU/DFcGAkOYQUNvk4nfrW0N973/khBAp6/k5I7M4Np4LmMuX1+Vec5s42g1KzmB5BnBZrKT60VP8fxlGk/x8AXag8td19hmrwWEkcjas1sMiwVUwjEIzPNuzwy6GTQBI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=b3rMw32A; arc=none smtp.client-ip=192.198.163.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none 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="b3rMw32A" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1741705344; x=1773241344; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=coDGYA3G+yyYMnLYZxfS8hKebjAu/7The5gGiic6xpY=; b=b3rMw32Aik6E4R9EDODTw76jBMOE5Qfb/2NqNL+Nl4BqE6eq2uh96L62 xyVhbWUQo0RxvXIGhNgrxofT5puYXb0MS+GaguwLE98mLWuUxRhN3OR3n eJQy3kS4zVfh9J7JPbkS6/fDDZF6D902Gj+DuE+hnhkH1uPuBGNlog/6I nYx/fCTDQuqZZfrpQAgyNmlnfyWNOdMZ8ftMM8/gYmmh5epGzto0UpbU4 /ETMDXM520B3ZwcKK6aHuLNcO312lJiNGQdvJf8JwYSVQvfVGMUu+B2Ki DdrGPmW58q8CMKbxJ4hsm0drG1QczrZNog7ymmHb58/+LL0GqEWRcSY4o A==; X-CSE-ConnectionGUID: mZ5ufaBQTcG2JvdBsDSK5w== X-CSE-MsgGUID: c7ppipNIQRqTsoR52JYn8w== X-IronPort-AV: E=McAfee;i="6700,10204,11370"; a="41917447" X-IronPort-AV: E=Sophos;i="6.14,239,1736841600"; d="scan'208";a="41917447" Received: from orviesa004.jf.intel.com ([10.64.159.144]) by fmvoesa113.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2025 08:02:21 -0700 X-CSE-ConnectionGUID: iOMH0CoKR9qhkb0VGUQIPA== X-CSE-MsgGUID: qtHltlHCT5igNO7pqzrtmw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,239,1736841600"; d="scan'208";a="125388480" Received: from ghakimel-mobl.amr.corp.intel.com (HELO desk) ([10.125.145.184]) by orviesa004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2025 08:02:21 -0700 Date: Tue, 11 Mar 2025 08:02:20 -0700 From: Pawan Gupta To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: daniel.sneddon@linux.intel.com, tony.luck@intel.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-perf-users@vger.kernel.org, Josh Poimboeuf , Srinivas Pandruvada , "Rafael J. Wysocki" , Ricardo Neri , "Liang, Kan" , Andrew Cooper , Brice Goglin , Mario Limonciello , Perry Yuan , Dapeng Mi Subject: [PATCH v8 2/5] x86/cpu: Name CPU matching macro more generically (and shorten) Message-ID: <20250311-add-cpu-type-v8-2-e8514dcaaff2@linux.intel.com> X-Mailer: b4 0.14.1 References: <20250311-add-cpu-type-v8-0-e8514dcaaff2@linux.intel.com> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250311-add-cpu-type-v8-0-e8514dcaaff2@linux.intel.com> To add cpu-type to the existing CPU matching infrastructure, the base macro X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE need to append _CPU_TYPE. This makes an already long name longer, and somewhat incomprehensible. To avoid this, rename the base macro to X86_MATCH_CPU. The macro name doesn't need to explicitly tell everything that it matches. The arguments to the macro already hints that. For consistency, use this base macro to define X86_MATCH_VFM and friends. Acked-by: Dave Hansen Signed-off-by: Pawan Gupta --- arch/x86/include/asm/cpu_device_id.h | 110 +++++++++-------------------------- 1 file changed, 26 insertions(+), 84 deletions(-) diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h index 9ebc263832ff..45489b034cd6 100644 --- a/arch/x86/include/asm/cpu_device_id.h +++ b/arch/x86/include/asm/cpu_device_id.h @@ -57,7 +57,7 @@ #define X86_CPU_ID_FLAG_ENTRY_VALID BIT(0) /** - * X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE - Base macro for CPU matching + * X86_MATCH_CPU - Base macro for CPU matching * @_vendor: The vendor name, e.g. INTEL, AMD, HYGON, ..., ANY * The name is expanded to X86_VENDOR_@_vendor * @_family: The family number or X86_FAMILY_ANY @@ -74,19 +74,7 @@ * into another macro at the usage site for good reasons, then please * start this local macro with X86_MATCH to allow easy grepping. */ -#define X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(_vendor, _family, _model, \ - _steppings, _feature, _data) { \ - .vendor = X86_VENDOR_##_vendor, \ - .family = _family, \ - .model = _model, \ - .steppings = _steppings, \ - .feature = _feature, \ - .flags = X86_CPU_ID_FLAG_ENTRY_VALID, \ - .driver_data = (unsigned long) _data \ -} - -#define X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE(_vendor, _family, _model, \ - _steppings, _feature, _data) { \ +#define X86_MATCH_CPU(_vendor, _family, _model, _steppings, _feature, _data) { \ .vendor = _vendor, \ .family = _family, \ .model = _model, \ @@ -96,24 +84,6 @@ .driver_data = (unsigned long) _data \ } -/** - * X86_MATCH_VENDOR_FAM_MODEL_FEATURE - Macro for CPU matching - * @_vendor: The vendor name, e.g. INTEL, AMD, HYGON, ..., ANY - * The name is expanded to X86_VENDOR_@_vendor - * @_family: The family number or X86_FAMILY_ANY - * @_model: The model number, model constant or X86_MODEL_ANY - * @_feature: A X86_FEATURE bit or X86_FEATURE_ANY - * @_data: Driver specific data or NULL. The internal storage - * format is unsigned long. The supplied value, pointer - * etc. is casted to unsigned long internally. - * - * The steppings arguments of X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE() is - * set to wildcards. - */ -#define X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, model, feature, data) \ - X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(vendor, family, model, \ - X86_STEPPING_ANY, feature, data) - /** * X86_MATCH_VENDOR_FAM_FEATURE - Macro for matching vendor, family and CPU feature * @vendor: The vendor name, e.g. INTEL, AMD, HYGON, ..., ANY @@ -123,13 +93,10 @@ * @data: Driver specific data or NULL. The internal storage * format is unsigned long. The supplied value, pointer * etc. is casted to unsigned long internally. - * - * All other missing arguments of X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are - * set to wildcards. */ -#define X86_MATCH_VENDOR_FAM_FEATURE(vendor, family, feature, data) \ - X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, \ - X86_MODEL_ANY, feature, data) +#define X86_MATCH_VENDOR_FAM_FEATURE(vendor, family, feature, data) \ + X86_MATCH_CPU(X86_VENDOR_##vendor, family, X86_MODEL_ANY, \ + X86_STEPPING_ANY, feature, data) /** * X86_MATCH_VENDOR_FEATURE - Macro for matching vendor and CPU feature @@ -139,12 +106,10 @@ * @data: Driver specific data or NULL. The internal storage * format is unsigned long. The supplied value, pointer * etc. is casted to unsigned long internally. - * - * All other missing arguments of X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are - * set to wildcards. */ -#define X86_MATCH_VENDOR_FEATURE(vendor, feature, data) \ - X86_MATCH_VENDOR_FAM_FEATURE(vendor, X86_FAMILY_ANY, feature, data) +#define X86_MATCH_VENDOR_FEATURE(vendor, feature, data) \ + X86_MATCH_CPU(X86_VENDOR_##vendor, X86_FAMILY_ANY, X86_MODEL_ANY, \ + X86_STEPPING_ANY, feature, data) /** * X86_MATCH_FEATURE - Macro for matching a CPU feature @@ -152,12 +117,10 @@ * @data: Driver specific data or NULL. The internal storage * format is unsigned long. The supplied value, pointer * etc. is casted to unsigned long internally. - * - * All other missing arguments of X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are - * set to wildcards. */ -#define X86_MATCH_FEATURE(feature, data) \ - X86_MATCH_VENDOR_FEATURE(ANY, feature, data) +#define X86_MATCH_FEATURE(feature, data) \ + X86_MATCH_CPU(X86_VENDOR_ANY, X86_FAMILY_ANY, X86_MODEL_ANY, \ + X86_STEPPING_ANY, feature, data) /** * X86_MATCH_VENDOR_FAM_MODEL - Match vendor, family and model @@ -168,13 +131,10 @@ * @data: Driver specific data or NULL. The internal storage * format is unsigned long. The supplied value, pointer * etc. is casted to unsigned long internally. - * - * All other missing arguments of X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are - * set to wildcards. */ -#define X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, data) \ - X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, model, \ - X86_FEATURE_ANY, data) +#define X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, data) \ + X86_MATCH_CPU(X86_VENDOR_##vendor, family, model, X86_STEPPING_ANY, \ + X86_FEATURE_ANY, data) /** * X86_MATCH_VENDOR_FAM - Match vendor and family @@ -184,12 +144,10 @@ * @data: Driver specific data or NULL. The internal storage * format is unsigned long. The supplied value, pointer * etc. is casted to unsigned long internally. - * - * All other missing arguments to X86_MATCH_VENDOR_FAM_MODEL_FEATURE() are - * set of wildcards. */ -#define X86_MATCH_VENDOR_FAM(vendor, family, data) \ - X86_MATCH_VENDOR_FAM_MODEL(vendor, family, X86_MODEL_ANY, data) +#define X86_MATCH_VENDOR_FAM(vendor, family, data) \ + X86_MATCH_CPU(X86_VENDOR_##vendor, family, X86_MODEL_ANY, \ + X86_STEPPING_ANY, X86_FEATURE_ANY, data) /** * X86_MATCH_VFM - Match encoded vendor/family/model @@ -197,15 +155,10 @@ * @data: Driver specific data or NULL. The internal storage * format is unsigned long. The supplied value, pointer * etc. is cast to unsigned long internally. - * - * Stepping and feature are set to wildcards */ -#define X86_MATCH_VFM(vfm, data) \ - X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE( \ - VFM_VENDOR(vfm), \ - VFM_FAMILY(vfm), \ - VFM_MODEL(vfm), \ - X86_STEPPING_ANY, X86_FEATURE_ANY, data) +#define X86_MATCH_VFM(vfm, data) \ + X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \ + X86_STEPPING_ANY, X86_FEATURE_ANY, data) #define __X86_STEPPINGS(mins, maxs) GENMASK(maxs, mins) /** @@ -217,16 +170,10 @@ * @data: Driver specific data or NULL. The internal storage * format is unsigned long. The supplied value, pointer * etc. is cast to unsigned long internally. - * - * feature is set to wildcard */ -#define X86_MATCH_VFM_STEPS(vfm, min_step, max_step, data) \ - X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE( \ - VFM_VENDOR(vfm), \ - VFM_FAMILY(vfm), \ - VFM_MODEL(vfm), \ - __X86_STEPPINGS(min_step, max_step), \ - X86_FEATURE_ANY, data) +#define X86_MATCH_VFM_STEPS(vfm, min_step, max_step, data) \ + X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \ + __X86_STEPPINGS(min_step, max_step), X86_FEATURE_ANY, data) /** * X86_MATCH_VFM_FEATURE - Match encoded vendor/family/model/feature @@ -235,15 +182,10 @@ * @data: Driver specific data or NULL. The internal storage * format is unsigned long. The supplied value, pointer * etc. is cast to unsigned long internally. - * - * Steppings is set to wildcard */ -#define X86_MATCH_VFM_FEATURE(vfm, feature, data) \ - X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE( \ - VFM_VENDOR(vfm), \ - VFM_FAMILY(vfm), \ - VFM_MODEL(vfm), \ - X86_STEPPING_ANY, feature, data) +#define X86_MATCH_VFM_FEATURE(vfm, feature, data) \ + X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \ + X86_STEPPING_ANY, feature, data) extern const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match); extern bool x86_match_min_microcode_rev(const struct x86_cpu_id *table); From patchwork Tue Mar 11 15:02:36 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pawan Gupta X-Patchwork-Id: 872738 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) (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 9932125DAEF; Tue, 11 Mar 2025 15:02:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741705360; cv=none; b=Xb5Vjsw46eVKWkXITPcuqVLbhEU7HLXdx/4SeAUp1nSv2tJO7+i9uCXtECADq+oA0Vw8MAaVpEwa1+eo4OffpoT+FrApg3lYnqGzsmsAy07LQWjgNb0P4lZahxfhO+ZVtJTo0s72FSKlQkSsA48sAY6nXFqf72zmoQyMfXmXTuw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741705360; c=relaxed/simple; bh=1xzgPaIVTKd3kJ0RH1k1vY+x5MN32kaFJxGhbP75sWM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QFO0zS+56V8fxJgKpveVXqWx+z5nYVCBqTGiP9ccIS8tK6hmT1UBy4UurOZVQl6w04Tkwp9T4Jxr9y9ZKDUmMAoqk9eCIL6oGEZHcSva/zMefLiCBSfP4jjLIffZqz9zttkI5wglmQYXWxYUlFfq9U4JKHPigfc65IQx1VanYMA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=SRsE992e; arc=none smtp.client-ip=192.198.163.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none 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="SRsE992e" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1741705359; x=1773241359; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=1xzgPaIVTKd3kJ0RH1k1vY+x5MN32kaFJxGhbP75sWM=; b=SRsE992erd4wmv7PquQjvH7XFzzCaQzc8D0YAhXnErgoS8GINJulxc4n W0OupvYNQQmJIny77snIQTVCakN2xnVcaYSlg/vLMwD5MokKGLdq2UMoC 3TKz4dQOzmR0IipPt8x9N5fK8HGwLTrrlhmjm0Y8ky1H12eByaYb7sQNc dpXOAtAN9VmaD2e00H/Em28unWp4So1wInkcI37/VG+K1wt6uB1uBvcmS jCn/SsM/zK8D5rwAz9zm5E4EgTH4eeTAjmHkWxtA6ovaahu8DT+KARy6Z XEM1UNcjODDn3b46VgdEz4yga4HzrT4s4MXT72B1nQqbGXHfMtVS2avuo w==; X-CSE-ConnectionGUID: fH+vdpUxRtOmprrrKukTpg== X-CSE-MsgGUID: Kg7JEKEgSaSKMUaXlbC/RQ== X-IronPort-AV: E=McAfee;i="6700,10204,11370"; a="53373347" X-IronPort-AV: E=Sophos;i="6.14,239,1736841600"; d="scan'208";a="53373347" Received: from fmviesa005.fm.intel.com ([10.60.135.145]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2025 08:02:38 -0700 X-CSE-ConnectionGUID: 7kdbi+JXQf63S/tUDWCmuw== X-CSE-MsgGUID: Lgre5NjZTVq9j6lB4/SAbg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,239,1736841600"; d="scan'208";a="124958192" Received: from ghakimel-mobl.amr.corp.intel.com (HELO desk) ([10.125.145.184]) by fmviesa005-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2025 08:02:37 -0700 Date: Tue, 11 Mar 2025 08:02:36 -0700 From: Pawan Gupta To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: daniel.sneddon@linux.intel.com, tony.luck@intel.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-perf-users@vger.kernel.org, Josh Poimboeuf , Srinivas Pandruvada , "Rafael J. Wysocki" , Ricardo Neri , "Liang, Kan" , Andrew Cooper , Brice Goglin , Mario Limonciello , Perry Yuan , Dapeng Mi Subject: [PATCH v8 3/5] x86/cpu: Add cpu_type to struct x86_cpu_id Message-ID: <20250311-add-cpu-type-v8-3-e8514dcaaff2@linux.intel.com> X-Mailer: b4 0.14.1 References: <20250311-add-cpu-type-v8-0-e8514dcaaff2@linux.intel.com> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250311-add-cpu-type-v8-0-e8514dcaaff2@linux.intel.com> In addition to matching vendor/family/model/feature, for hybrid variants it is required to also match cpu-type also. For example some CPU vulnerabilities like RFDS only affects a specific cpu-type. To be able to also match CPUs based on their type, add a new field cpu_type to struct x86_cpu_id which is used by the CPU-matching tables. Introduce X86_CPU_TYPE_ANY for the cases that don't care about the cpu-type. Acked-by: Dave Hansen Signed-off-by: Pawan Gupta --- arch/x86/include/asm/cpu_device_id.h | 32 +++++++++++++++++++++++--------- include/linux/mod_devicetable.h | 2 ++ 2 files changed, 25 insertions(+), 9 deletions(-) diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h index 45489b034cd6..6be777a06944 100644 --- a/arch/x86/include/asm/cpu_device_id.h +++ b/arch/x86/include/asm/cpu_device_id.h @@ -74,13 +74,14 @@ * into another macro at the usage site for good reasons, then please * start this local macro with X86_MATCH to allow easy grepping. */ -#define X86_MATCH_CPU(_vendor, _family, _model, _steppings, _feature, _data) { \ +#define X86_MATCH_CPU(_vendor, _family, _model, _steppings, _feature, _type, _data) { \ .vendor = _vendor, \ .family = _family, \ .model = _model, \ .steppings = _steppings, \ .feature = _feature, \ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, \ + .type = _type, \ .driver_data = (unsigned long) _data \ } @@ -96,7 +97,7 @@ */ #define X86_MATCH_VENDOR_FAM_FEATURE(vendor, family, feature, data) \ X86_MATCH_CPU(X86_VENDOR_##vendor, family, X86_MODEL_ANY, \ - X86_STEPPING_ANY, feature, data) + X86_STEPPING_ANY, feature, X86_CPU_TYPE_ANY, data) /** * X86_MATCH_VENDOR_FEATURE - Macro for matching vendor and CPU feature @@ -109,7 +110,7 @@ */ #define X86_MATCH_VENDOR_FEATURE(vendor, feature, data) \ X86_MATCH_CPU(X86_VENDOR_##vendor, X86_FAMILY_ANY, X86_MODEL_ANY, \ - X86_STEPPING_ANY, feature, data) + X86_STEPPING_ANY, feature, X86_CPU_TYPE_ANY, data) /** * X86_MATCH_FEATURE - Macro for matching a CPU feature @@ -120,7 +121,7 @@ */ #define X86_MATCH_FEATURE(feature, data) \ X86_MATCH_CPU(X86_VENDOR_ANY, X86_FAMILY_ANY, X86_MODEL_ANY, \ - X86_STEPPING_ANY, feature, data) + X86_STEPPING_ANY, feature, X86_CPU_TYPE_ANY, data) /** * X86_MATCH_VENDOR_FAM_MODEL - Match vendor, family and model @@ -134,7 +135,7 @@ */ #define X86_MATCH_VENDOR_FAM_MODEL(vendor, family, model, data) \ X86_MATCH_CPU(X86_VENDOR_##vendor, family, model, X86_STEPPING_ANY, \ - X86_FEATURE_ANY, data) + X86_FEATURE_ANY, X86_CPU_TYPE_ANY, data) /** * X86_MATCH_VENDOR_FAM - Match vendor and family @@ -147,7 +148,7 @@ */ #define X86_MATCH_VENDOR_FAM(vendor, family, data) \ X86_MATCH_CPU(X86_VENDOR_##vendor, family, X86_MODEL_ANY, \ - X86_STEPPING_ANY, X86_FEATURE_ANY, data) + X86_STEPPING_ANY, X86_FEATURE_ANY, X86_CPU_TYPE_ANY, data) /** * X86_MATCH_VFM - Match encoded vendor/family/model @@ -158,7 +159,7 @@ */ #define X86_MATCH_VFM(vfm, data) \ X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \ - X86_STEPPING_ANY, X86_FEATURE_ANY, data) + X86_STEPPING_ANY, X86_FEATURE_ANY, X86_CPU_TYPE_ANY, data) #define __X86_STEPPINGS(mins, maxs) GENMASK(maxs, mins) /** @@ -173,7 +174,8 @@ */ #define X86_MATCH_VFM_STEPS(vfm, min_step, max_step, data) \ X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \ - __X86_STEPPINGS(min_step, max_step), X86_FEATURE_ANY, data) + __X86_STEPPINGS(min_step, max_step), X86_FEATURE_ANY, \ + X86_CPU_TYPE_ANY, data) /** * X86_MATCH_VFM_FEATURE - Match encoded vendor/family/model/feature @@ -185,7 +187,19 @@ */ #define X86_MATCH_VFM_FEATURE(vfm, feature, data) \ X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \ - X86_STEPPING_ANY, feature, data) + X86_STEPPING_ANY, feature, X86_CPU_TYPE_ANY, data) + +/** + * X86_MATCH_VFM_CPU_TYPE - Match encoded vendor/family/model/type + * @vfm: Encoded 8-bits each for vendor, family, model + * @type: CPU type e.g. P-core, E-core + * @data: Driver specific data or NULL. The internal storage + * format is unsigned long. The supplied value, pointer + * etc. is cast to unsigned long internally. + */ +#define X86_MATCH_VFM_CPU_TYPE(vfm, type, data) \ + X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \ + X86_STEPPING_ANY, X86_FEATURE_ANY, type, data) extern const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match); extern bool x86_match_min_microcode_rev(const struct x86_cpu_id *table); diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h index d67614f7b7f1..bd7e60c0b72f 100644 --- a/include/linux/mod_devicetable.h +++ b/include/linux/mod_devicetable.h @@ -692,6 +692,7 @@ struct x86_cpu_id { __u16 feature; /* bit index */ /* Solely for kernel-internal use: DO NOT EXPORT to userspace! */ __u16 flags; + __u8 type; kernel_ulong_t driver_data; }; @@ -703,6 +704,7 @@ struct x86_cpu_id { #define X86_STEP_MIN 0 #define X86_STEP_MAX 0xf #define X86_FEATURE_ANY 0 /* Same as FPU, you can't test for that */ +#define X86_CPU_TYPE_ANY 0 /* * Generic table type for matching CPU features. From patchwork Tue Mar 11 15:02:52 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pawan Gupta X-Patchwork-Id: 873010 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 8335025D8E8; Tue, 11 Mar 2025 15:02:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741705376; cv=none; b=mezcAvm3WiiE0TZtYw1UBCzZyAyzz5XzWr/kjOFvBBZBDpjra7NVkFZ1/TXnv9ObBxjeVA+30Wox7aw/+O+mRJLDDPfFsR6A69ss9empeIPP87w9q3AzmuPz2cf2T1aZ0qdaDqJ7v0ZYK5N1i1FPSrxoFvVHytJ5KteA+rtlgfQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741705376; c=relaxed/simple; bh=mxJf1kp4ViaD2arBJYw/68nBhcshUVhAMv/hUp21Mqs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ad1ZzPHKSgGNxcDXhIsXSOOULUqACbnGzoWR5MvG0LRBBYebeHDrLyl0RT2ehEWAFpnHUP5ASMWtDBPPF7qN9bgfweBtMIbQA0483hYxeuH9qB5yhslQCezxppyLTfwHLuQ5iSgrdZJG5c/LYdaykmX/DNDKIBFJL3/0NEXGLVE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=bu84eCFy; arc=none smtp.client-ip=192.198.163.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none 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="bu84eCFy" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1741705374; x=1773241374; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=mxJf1kp4ViaD2arBJYw/68nBhcshUVhAMv/hUp21Mqs=; b=bu84eCFy8CriduFmAbFVV4eiJ/y92fD4t1ayAbaSTHwYcNZfoJEmRKWM 38MTiGhKkGwiz4j96UAC6YwBknK+pqcylnK5XJsBEzTy5/miUhSN/wprG EvPxUBIekxSChPQ2lbGc5Po2badMmJdw5l+67KGmZUpkX0CrOCSgFgpC1 BHPa4nTN98G2qmRmuFi+Oe7FWWKbPW6GrcdLB+TTfbr8nZYENxyZOZBCC TcmUAGbb/Axz0ag4BGEt4yZSKxzfR2wqb63NMe5gRbzEFPG7kbNB8pGD+ gz66y9+zzQr1tmI5t1LpTSq/uOdmwJNVNXX+SL4wnDYpuKjaQI7oruTDl Q==; X-CSE-ConnectionGUID: x288dQ2kSPaqukeWNAKRlA== X-CSE-MsgGUID: EFimYKbiTQybL+9wneW8DA== X-IronPort-AV: E=McAfee;i="6700,10204,11370"; a="42624665" X-IronPort-AV: E=Sophos;i="6.14,239,1736841600"; d="scan'208";a="42624665" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2025 08:02:53 -0700 X-CSE-ConnectionGUID: apCygz93SiKCyso39/YEJA== X-CSE-MsgGUID: n1Go5hoNRheB+/2GCOHbxg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,239,1736841600"; d="scan'208";a="120297618" Received: from ghakimel-mobl.amr.corp.intel.com (HELO desk) ([10.125.145.184]) by orviesa006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2025 08:02:54 -0700 Date: Tue, 11 Mar 2025 08:02:52 -0700 From: Pawan Gupta To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: daniel.sneddon@linux.intel.com, tony.luck@intel.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-perf-users@vger.kernel.org, Josh Poimboeuf , Srinivas Pandruvada , "Rafael J. Wysocki" , Ricardo Neri , "Liang, Kan" , Andrew Cooper , Brice Goglin , Mario Limonciello , Perry Yuan , Dapeng Mi Subject: [PATCH v8 4/5] x86/cpu: Update x86_match_cpu() to also use cpu-type Message-ID: <20250311-add-cpu-type-v8-4-e8514dcaaff2@linux.intel.com> X-Mailer: b4 0.14.1 References: <20250311-add-cpu-type-v8-0-e8514dcaaff2@linux.intel.com> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250311-add-cpu-type-v8-0-e8514dcaaff2@linux.intel.com> Non-hybrid CPU variants that share the same Family/Model could be differentiated by their cpu-type. x86_match_cpu() currently does not use cpu-type for CPU matching. Dave Hansen suggested to use below conditions to match CPU-type: 1. If CPU_TYPE_ANY (the wildcard), then matched 2. If hybrid, then matched 3. If !hybrid, look at the boot CPU and compare the cpu-type to determine if it is a match. This special case for hybrid systems allows more compact vulnerability list. Imagine that "Haswell" CPUs might or might not be hybrid and that only Atom cores are vulnerable to Meltdown. That means there are three possibilities: 1. P-core only 2. Atom only 3. Atom + P-core (aka. hybrid) One might be tempted to code up the vulnerability list like this: MATCH( HASWELL, X86_FEATURE_HYBRID, MELTDOWN) MATCH_TYPE(HASWELL, ATOM, MELTDOWN) Logically, this matches #2 and #3. But that's a little silly. You would only ask for the "ATOM" match in cases where there *WERE* hybrid cores in play. You shouldn't have to _also_ ask for hybrid cores explicitly. In short, assume that processors that enumerate Hybrid==1 have a vulnerable core type. Update x86_match_cpu() to also match cpu-type. Also treat hybrid systems as special, and match them to any cpu-type. Suggested-by: Dave Hansen Acked-by: Dave Hansen Signed-off-by: Pawan Gupta --- arch/x86/kernel/cpu/match.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/arch/x86/kernel/cpu/match.c b/arch/x86/kernel/cpu/match.c index 4f3c65429f82..6af1e8baeb0f 100644 --- a/arch/x86/kernel/cpu/match.c +++ b/arch/x86/kernel/cpu/match.c @@ -5,6 +5,34 @@ #include #include +/** + * x86_match_vendor_cpu_type - helper function to match the hardware defined + * cpu-type for a single entry in the x86_cpu_id + * table. Note, this function does not match the + * generic cpu-types TOPO_CPU_TYPE_EFFICIENCY and + * TOPO_CPU_TYPE_PERFORMANCE. + * @c: Pointer to the cpuinfo_x86 structure of the CPU to match. + * @m: Pointer to the x86_cpu_id entry to match against. + * + * Return: true if the cpu-type matches, false otherwise. + */ +static bool x86_match_vendor_cpu_type(struct cpuinfo_x86 *c, const struct x86_cpu_id *m) +{ + if (m->type == X86_CPU_TYPE_ANY) + return true; + + /* Hybrid CPUs are special, they are assumed to match all cpu-types */ + if (cpu_feature_enabled(X86_FEATURE_HYBRID_CPU)) + return true; + + if (c->x86_vendor == X86_VENDOR_INTEL) + return m->type == c->topo.intel_type; + if (c->x86_vendor == X86_VENDOR_AMD) + return m->type == c->topo.amd_type; + + return false; +} + /** * x86_match_cpu - match current CPU against an array of x86_cpu_ids * @match: Pointer to array of x86_cpu_ids. Last entry terminated with @@ -50,6 +78,8 @@ const struct x86_cpu_id *x86_match_cpu(const struct x86_cpu_id *match) continue; if (m->feature != X86_FEATURE_ANY && !cpu_has(c, m->feature)) continue; + if (!x86_match_vendor_cpu_type(c, m)) + continue; return m; } return NULL; From patchwork Tue Mar 11 15:03:08 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pawan Gupta X-Patchwork-Id: 872737 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.17]) (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 7284525E833; Tue, 11 Mar 2025 15:03:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.17 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741705395; cv=none; b=ccBz6Kn54n81iklLY6djKaM21XydUXJrbNFklyji1QfXQUPaFg1aapjwSK6tNXBLemNA2nMufN/q8MI5mX+XKCztNg90SYCY8OIr0eW/ICsxQKBlQ524TegZgTqs0Jsj7lwHRURhJTHyKO0rrTr5dTHz2hifcDT/ViVU9730PVs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741705395; c=relaxed/simple; bh=BBNjOQP4CmwaTxuMkTvDmx+aoMhLUR9wQq+c3rEV3ww=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=p0aueHQOg5mbpgN7NYpBa8PXKy1UJpKBw6ZpP1XQwP32gZm3dm9nM9Wkzx8pK+ud/uLw6OqA/yPKLa9EgxrD+/cgI3B4F8yMrreVoEb/O4g4OzGR1tDZxMb00YIV/GBCgJC6P+vDgJhDxpoDvHnHOmGsseIG0Htfv3YzMobG/vQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=h51z9ruA; arc=none smtp.client-ip=192.198.163.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none 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="h51z9ruA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1741705393; x=1773241393; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=BBNjOQP4CmwaTxuMkTvDmx+aoMhLUR9wQq+c3rEV3ww=; b=h51z9ruAorpoYZYvh5+0GKQ2N6Lkhwp4PtaHJHaSH3u50ZdG/P4d99Yy siDEu/kM0c/wJEF/6zXlt2x+dgsEmkYxJoC+QfMYCOeY6SSvutT+hEfBT wIYQ2fuOrXcZOkOSek8RckN19w7FRCwzR9pGqiWrm/DEoQXH6iFZC7qJL UFaMvjEej0DHMq+L8NnlpimzfXtEm37mBAFDBNb0SIydTeD2JIU6KUw1J mEGqP5v8M3VH6WR7SVWXXXTVgpqhfX/YxBF9R1uZD2VOu2gt3fR9ZqJnb 373jbdoP932YWSMAV1bq/o1JH7Nc22yc1TLfMcUvRgL0LS/QtmlezRQdm w==; X-CSE-ConnectionGUID: R2OZ5TyJQvaF2O8tkWKSJw== X-CSE-MsgGUID: PAZnEcDvTE6duNpSW3K39A== X-IronPort-AV: E=McAfee;i="6700,10204,11370"; a="42624789" X-IronPort-AV: E=Sophos;i="6.14,239,1736841600"; d="scan'208";a="42624789" Received: from orviesa006.jf.intel.com ([10.64.159.146]) by fmvoesa111.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2025 08:03:10 -0700 X-CSE-ConnectionGUID: cJ+j8wTwTbq8zuGjrlxa7A== X-CSE-MsgGUID: 0imJHXiJRxS95eLQXhg/Zg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.14,239,1736841600"; d="scan'208";a="120297721" Received: from ghakimel-mobl.amr.corp.intel.com (HELO desk) ([10.125.145.184]) by orviesa006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Mar 2025 08:03:09 -0700 Date: Tue, 11 Mar 2025 08:03:08 -0700 From: Pawan Gupta To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: daniel.sneddon@linux.intel.com, tony.luck@intel.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-perf-users@vger.kernel.org, Josh Poimboeuf , Srinivas Pandruvada , "Rafael J. Wysocki" , Ricardo Neri , "Liang, Kan" , Andrew Cooper , Brice Goglin , Mario Limonciello , Perry Yuan , Dapeng Mi Subject: [PATCH v8 5/5] x86/rfds: Exclude P-only parts from the RFDS affected list Message-ID: <20250311-add-cpu-type-v8-5-e8514dcaaff2@linux.intel.com> X-Mailer: b4 0.14.1 References: <20250311-add-cpu-type-v8-0-e8514dcaaff2@linux.intel.com> Precedence: bulk X-Mailing-List: linux-pm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20250311-add-cpu-type-v8-0-e8514dcaaff2@linux.intel.com> The affected CPU table (cpu_vuln_blacklist) marks Alderlake and Raptorlake P-only parts affected by RFDS. This is not true because only E-cores are affected by RFDS. With the current family/model matching it is not possible to differentiate the unaffected parts, as the affected and unaffected hybrid variants have the same model number. Add a cpu-type match as well for such parts so as to exclude P-only parts being marked as affected. Note, family/model and cpu-type enumeration could be inaccurate in virtualized environments. In a guest affected status is decided by RFDS_NO and RFDS_CLEAR bits exposed by VMMs. Acked-by: Dave Hansen Signed-off-by: Pawan Gupta --- Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst | 8 -------- arch/x86/kernel/cpu/common.c | 7 +++++-- 2 files changed, 5 insertions(+), 10 deletions(-) diff --git a/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst index 0585d02b9a6c..ad15417d39f9 100644 --- a/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst +++ b/Documentation/admin-guide/hw-vuln/reg-file-data-sampling.rst @@ -29,14 +29,6 @@ Below is the list of affected Intel processors [#f1]_: RAPTORLAKE_S 06_BFH =================== ============ -As an exception to this table, Intel Xeon E family parts ALDERLAKE(06_97H) and -RAPTORLAKE(06_B7H) codenamed Catlow are not affected. They are reported as -vulnerable in Linux because they share the same family/model with an affected -part. Unlike their affected counterparts, they do not enumerate RFDS_CLEAR or -CPUID.HYBRID. This information could be used to distinguish between the -affected and unaffected parts, but it is deemed not worth adding complexity as -the reporting is fixed automatically when these parts enumerate RFDS_NO. - Mitigation ========== Intel released a microcode update that enables software to clear sensitive diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 5f81c553e733..92fe56c40238 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1203,6 +1203,9 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = { #define VULNBL_INTEL_STEPS(vfm, max_stepping, issues) \ X86_MATCH_VFM_STEPS(vfm, X86_STEP_MIN, max_stepping, issues) +#define VULNBL_INTEL_TYPE(vfm, cpu_type, issues) \ + X86_MATCH_VFM_CPU_TYPE(vfm, INTEL_CPU_TYPE_##cpu_type, issues) + #define VULNBL_AMD(family, blacklist) \ VULNBL(AMD, family, X86_MODEL_ANY, blacklist) @@ -1251,9 +1254,9 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = { VULNBL_INTEL_STEPS(INTEL_TIGERLAKE, X86_STEP_MAX, GDS), VULNBL_INTEL_STEPS(INTEL_LAKEFIELD, X86_STEP_MAX, MMIO | MMIO_SBDS | RETBLEED), VULNBL_INTEL_STEPS(INTEL_ROCKETLAKE, X86_STEP_MAX, MMIO | RETBLEED | GDS), - VULNBL_INTEL_STEPS(INTEL_ALDERLAKE, X86_STEP_MAX, RFDS), + VULNBL_INTEL_TYPE(INTEL_ALDERLAKE, ATOM, RFDS), VULNBL_INTEL_STEPS(INTEL_ALDERLAKE_L, X86_STEP_MAX, RFDS), - VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE, X86_STEP_MAX, RFDS), + VULNBL_INTEL_TYPE(INTEL_RAPTORLAKE, ATOM, RFDS), VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE_P, X86_STEP_MAX, RFDS), VULNBL_INTEL_STEPS(INTEL_RAPTORLAKE_S, X86_STEP_MAX, RFDS), VULNBL_INTEL_STEPS(INTEL_ATOM_GRACEMONT, X86_STEP_MAX, RFDS),