From patchwork Mon Jun 17 09:11:26 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pawan Gupta X-Patchwork-Id: 805143 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (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 67E5A19148B; Mon, 17 Jun 2024 09:11:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718615490; cv=none; b=Wqh+ftYBlrqbLoywpTSRarXLg12xb7I4SwlSJ2rXqpL4tTAvRJznHCwkewATNKKIPyCnxtBarCjpK3FP5exUN6QSQjhixh+hsXWWFYdEZtUYcKp0W8++Y446hpbbAvs4rUMG2JLvnVFb9Dm9gwYVxhFmE9yDzGlled3f3iJJE30= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718615490; c=relaxed/simple; bh=55aFiixm2MiUW1iDk8Nvs7xIh7ZXfrnQ5T1cw9UfRvs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Vv7nmLd7MyXoGGxbKvnevM/spOnplFPexf6tjg1aF5w+A6viWpmri1bqyqmqK+27VM9at2To1NDADm1CuJxS6hk5te2TRXy0ITTIAH2BK8ewCOubBbt1b2xtGp+6n+YbGPVRvPsB4ZIL+rqqSI1HiVB0iy7qJfAe8r+79jRpH7k= 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=aUbbmTdI; arc=none smtp.client-ip=198.175.65.10 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="aUbbmTdI" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1718615489; x=1750151489; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=55aFiixm2MiUW1iDk8Nvs7xIh7ZXfrnQ5T1cw9UfRvs=; b=aUbbmTdINnMgm0mHY+VBvGP4EnVCLWw+/9QOroB92Ugz16C1dxJox0XW 0b3/vGGsjegOHyd2/HswHPJlcTH53OhJ8RMWlsa2DeBbqKFyMcSZkT3OO dlryEkL3VUnwgddJxN/yQFcDG8wx55gG/inIlzLsU5KnNVJICAISvKtV2 DK8qrJBQCmoEi38n3nZrLdu1ICjMtTQtIrnY/5suqKv6BZDA/PPu810nd 4oXCW0i6Rqdb5eDEY/AfnD7MwnjvC1twOWQ6zg7A0RAtRYBzFr8SNBR4p DxmGkrN8X5AHzYyA8i2Jy5ydhZmYnCunGx2DQAed6c03+ujGofrk0bjr7 g==; X-CSE-ConnectionGUID: 4V1LvNaGRqSbqR7YJh/aTA== X-CSE-MsgGUID: 3rYGPa4wT9W3W5Ykb5bWRg== X-IronPort-AV: E=McAfee;i="6700,10204,11105"; a="32902522" X-IronPort-AV: E=Sophos;i="6.08,244,1712646000"; d="scan'208";a="32902522" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2024 02:11:28 -0700 X-CSE-ConnectionGUID: uxF7vehdR6Cte5mg/2vTvA== X-CSE-MsgGUID: 2Upe+dJxT2+aRJAMbSkOdg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,244,1712646000"; d="scan'208";a="72338836" Received: from mshehzad-mobl.amr.corp.intel.com (HELO desk) ([10.209.21.13]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2024 02:11:27 -0700 Date: Mon, 17 Jun 2024 02:11:26 -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 Subject: [PATCH PATCH 1/9] x86/cpu/topology: Add x86_cpu_type to struct cpuinfo_topology Message-ID: <20240617-add-cpu-type-v1-1-b88998c01e76@linux.intel.com> X-Mailer: b4 0.12.3 References: <20240617-add-cpu-type-v1-0-b88998c01e76@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: <20240617-add-cpu-type-v1-0-b88998c01e76@linux.intel.com> Sometimes it is required to identify the type of a core for taking specific actions e.g. intel_pstate driver uses the core type to determine CPU scaling. Also, some CPU vulnerabilities only affect a specific CPU type e.g. RFDS only affects Intel Atom. For hybrid systems that have variants P+E, P-only(Core) and E-only(Atom), it gets challenging to identify which variant is vulnerable to a specific vulnerability, as these variants share the same family, model and stepping. Such processors do have CPUID fields that uniquely identify them. Like, P+E, P-only and E-only enumerates CPUID.1A.CORE_TYPE, while P+E additionally enumerates CPUID.7.HYBRID. Linux does not currently use this field. Add a new field cpu_type to struct cpuinfo_topology which can be used to match a CPU based on its type. The cpu_type is populated in the below debugfs file: # cat /sys/kernel/debug/x86/topo/cpus/N Signed-off-by: Pawan Gupta --- arch/x86/include/asm/processor.h | 3 +++ arch/x86/include/asm/topology.h | 9 +++++++++ arch/x86/kernel/cpu/debugfs.c | 1 + arch/x86/kernel/cpu/topology_common.c | 9 +++++++++ 4 files changed, 22 insertions(+) diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h index cb4f6c513c48..f310a7fb4e00 100644 --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h @@ -95,6 +95,9 @@ struct cpuinfo_topology { // Core ID relative to the package u32 core_id; + // CPU-type e.g. performance, efficiency etc. + u8 cpu_type; + // Logical ID mappings u32 logical_pkg_id; u32 logical_die_id; diff --git a/arch/x86/include/asm/topology.h b/arch/x86/include/asm/topology.h index abe3a8f22cbd..b28ad9422afb 100644 --- a/arch/x86/include/asm/topology.h +++ b/arch/x86/include/asm/topology.h @@ -41,6 +41,14 @@ /* Mappings between logical cpu number and node number */ DECLARE_EARLY_PER_CPU(int, x86_cpu_to_node_map); +#define X86_CPU_TYPE_INTEL_SHIFT 24 + +enum x86_topo_cpu_type { + X86_CPU_TYPE_UNKNOWN = 0, + X86_CPU_TYPE_INTEL_ATOM = 0x20, + X86_CPU_TYPE_INTEL_CORE = 0x40, +}; + #ifdef CONFIG_DEBUG_PER_CPU_MAPS /* * override generic percpu implementation of cpu_to_node @@ -139,6 +147,7 @@ extern const struct cpumask *cpu_clustergroup_mask(int cpu); #define topology_logical_die_id(cpu) (cpu_data(cpu).topo.logical_die_id) #define topology_die_id(cpu) (cpu_data(cpu).topo.die_id) #define topology_core_id(cpu) (cpu_data(cpu).topo.core_id) +#define topology_cpu_type(cpu) (cpu_data(cpu).topo.cpu_type) #define topology_ppin(cpu) (cpu_data(cpu).ppin) #define topology_amd_node_id(cpu) (cpu_data(cpu).topo.amd_node_id) diff --git a/arch/x86/kernel/cpu/debugfs.c b/arch/x86/kernel/cpu/debugfs.c index 3baf3e435834..b1c9bafe6c39 100644 --- a/arch/x86/kernel/cpu/debugfs.c +++ b/arch/x86/kernel/cpu/debugfs.c @@ -22,6 +22,7 @@ static int cpu_debug_show(struct seq_file *m, void *p) seq_printf(m, "die_id: %u\n", c->topo.die_id); seq_printf(m, "cu_id: %u\n", c->topo.cu_id); seq_printf(m, "core_id: %u\n", c->topo.core_id); + seq_printf(m, "cpu_type: %x\n", c->topo.cpu_type); seq_printf(m, "logical_pkg_id: %u\n", c->topo.logical_pkg_id); seq_printf(m, "logical_die_id: %u\n", c->topo.logical_die_id); seq_printf(m, "llc_id: %u\n", c->topo.llc_id); diff --git a/arch/x86/kernel/cpu/topology_common.c b/arch/x86/kernel/cpu/topology_common.c index 9a6069e7133c..be82c8769bb2 100644 --- a/arch/x86/kernel/cpu/topology_common.c +++ b/arch/x86/kernel/cpu/topology_common.c @@ -140,6 +140,14 @@ static void parse_topology(struct topo_scan *tscan, bool early) } } +static void topo_set_cpu_type(struct cpuinfo_x86 *c) +{ + c->topo.cpu_type = X86_CPU_TYPE_UNKNOWN; + + if (c->x86_vendor == X86_VENDOR_INTEL && cpuid_eax(0) >= 0x1a) + c->topo.cpu_type = cpuid_eax(0x1a) >> X86_CPU_TYPE_INTEL_SHIFT; +} + static void topo_set_ids(struct topo_scan *tscan, bool early) { struct cpuinfo_x86 *c = tscan->c; @@ -190,6 +198,7 @@ void cpu_parse_topology(struct cpuinfo_x86 *c) } topo_set_ids(&tscan, false); + topo_set_cpu_type(c); } void __init cpu_init_topology(struct cpuinfo_x86 *c) From patchwork Mon Jun 17 09:11:38 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pawan Gupta X-Patchwork-Id: 805142 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) (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 3B74E194122; Mon, 17 Jun 2024 09:11:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.14 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718615500; cv=none; b=lsr3Qw4X75MSn0uVdI8kh7UAX07H+2fTpnR0wEAOi40L1LWNWca/9EbFueg5aifOqz1P+JvOmigbAZeyC0D8CxLartlMhXHHWBxplIFukCxcfNZxkEw0g2Yy1c1IPCmWwuPdSymTyTKNIfReLodfKE29YcJFQ7HPljrgY6IqtJE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718615500; c=relaxed/simple; bh=d/jAdioXM51F0WR6fWtrUjnIKIKYP2/LOVSFiVsdcq8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cgEo2TvOivXZEZTwkSii/ihHZDylmq304usAQR5O1MqRfnkLipCuRn/uHmcnjSvOrpubr/qfyOudY+VqOVcl80a7PyA7xWijGCKV3LB+kVAnpNczuRsISRbfYGATWvIjpdCen+gmXz/lMFaBnapzxY5Jjwhza4aA57uQpiXykL8= 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=I36YKfkC; arc=none smtp.client-ip=198.175.65.14 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="I36YKfkC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1718615499; x=1750151499; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=d/jAdioXM51F0WR6fWtrUjnIKIKYP2/LOVSFiVsdcq8=; b=I36YKfkCkICwUqPm4hVvVLFjhZaZ7Rn8XCB2TbM5Mk90EozF9PfGNEEs 3+FcDjeft9/n6eqGiUzYBExTXnCeaEh/4eOvGF75/nn/M9/+yJ5j2DvWQ jWb/mzzep/QL+mQzcSNx9shjs5iG5nr+MWTNdc+th+4kFT5F34IM5smZz zbF92H2hLonP65zXhRHg+2jr49vFazrTAfOpFMx/OqxY01CRBgraeSdn8 v/6K5vTQ26sCDJf4Me275J7tl+mPorwVxsCgicKyycDaIv/OUbU6QyaNE 4MljijBsovXdUSqgQZKb7kgb+1BGA5kwpMk3MTUkEMIQ4k5+wGJXV3VZx w==; X-CSE-ConnectionGUID: sCTyDIeMSuOIlhlqWITVmg== X-CSE-MsgGUID: JoXs2L3aQ2+a6Nu9caXmPA== X-IronPort-AV: E=McAfee;i="6700,10204,11105"; a="19257204" X-IronPort-AV: E=Sophos;i="6.08,244,1712646000"; d="scan'208";a="19257204" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2024 02:11:39 -0700 X-CSE-ConnectionGUID: kCcfN7uySlKaJx1u/xU9Kw== X-CSE-MsgGUID: MkDVGiYiSe6JV9+YCb7ZoQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,244,1712646000"; d="scan'208";a="41260337" Received: from mshehzad-mobl.amr.corp.intel.com (HELO desk) ([10.209.21.13]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2024 02:11:39 -0700 Date: Mon, 17 Jun 2024 02:11:38 -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 Subject: [PATCH PATCH 3/9] perf/x86/intel: Use topology_cpu_type() to get cpu-type Message-ID: <20240617-add-cpu-type-v1-3-b88998c01e76@linux.intel.com> X-Mailer: b4 0.12.3 References: <20240617-add-cpu-type-v1-0-b88998c01e76@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: <20240617-add-cpu-type-v1-0-b88998c01e76@linux.intel.com> find_hybrid_pmu_for_cpu() uses get_this_hybrid_cpu_type() to get the CPU type, but it returns an invalid cpu-type when X86_FEATURE_HYBRID_CPU is not set. Some hybrid variants do enumerate cpu-type regardless of X86_FEATURE_HYBRID_CPU. Replace get_this_hybrid_cpu_type() with topology_cpu_type() to get cpu-type irrespective of hybrid status. Moreover, get_this_hybrid_cpu_type() executes the CPUID instruction to get the cpu-type, which is slower than using the per-cpu value. Signed-off-by: Pawan Gupta --- arch/x86/events/intel/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index 38c1b1f1deaa..8067a735705a 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -4753,7 +4753,7 @@ static void intel_pmu_check_hybrid_pmus(struct x86_hybrid_pmu *pmu) static struct x86_hybrid_pmu *find_hybrid_pmu_for_cpu(void) { - u8 cpu_type = get_this_hybrid_cpu_type(); + u8 cpu_type = topology_cpu_type(smp_processor_id()); int i; /* From patchwork Mon Jun 17 09:11:50 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pawan Gupta X-Patchwork-Id: 805141 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.14]) (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 97A1C190665; Mon, 17 Jun 2024 09:11:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.14 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718615513; cv=none; b=lKf+gBaPrl9ivfLqYd9vUzkNl3uJVZBgMyD7mc9VeD8YmwsSSmarQgDc/WaDeVEETg8o1qvtw8+ZV1F7r/wofvlD3q4lwr/v5ABo+m6yGR5sR1ao9VFhuW5IvTfS76QopZ0hqzSAk02ImCzWx8NYkXtQ600L+h92u7fD5pBsQUU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718615513; c=relaxed/simple; bh=fdujHrXY5TjguA4JCpRyxjYQMm4wQQhKrrWjnggGMh0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=b7xfu4B+QkTfTTjlSQiSpneHuQOlFNnchzb0kJhXqOBvjLK2UxtE6XMOW/SOBHkoiIg0d4D6FB329xlbL2b7ga+1t4XAo4QU9klD9eZxZ8jA3ZRSdFrdRZftQh6DX5UjXjW2+uR1lBiLv2uYuMuENwPIApsO5WfjNCniqERQj3o= 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=G3vijsRY; arc=none smtp.client-ip=198.175.65.14 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="G3vijsRY" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1718615511; x=1750151511; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=fdujHrXY5TjguA4JCpRyxjYQMm4wQQhKrrWjnggGMh0=; b=G3vijsRYHQpEzt3mPjhpu8cEWCUt+b3z1lGZPbLbWL3Fqsfdtw78PRaN PHocY+1Qa4yT0Y0f0H7hL6V/cMgeC6sAjqOencpGzNLu2BeaJTyLZ5kWM fPrK3m4A1535RuNB+i5VHoGLDVck96N7py4Qqc8Q+touv8U0HkHOR1cXK oZt3YfHkgxZCT70LIPhLPaLuQ7qlUNbty6ThDsjdFzFxyxHMZw791cEiW HfO+2J1NvG+GfiXIrXUgorsARx1onsh/hXAziFjtTSmVpQsPLHenY+TA6 jZaojoVquDwZcvQ+jRKNUG+P62Bw5uB8J7bts3ANl90bcliu1eoD20u1y w==; X-CSE-ConnectionGUID: 1JHJcrFpTdmh66XJwXeYPw== X-CSE-MsgGUID: SD8xGXkKQVWMzaGc1FPWlQ== X-IronPort-AV: E=McAfee;i="6700,10204,11105"; a="19257232" X-IronPort-AV: E=Sophos;i="6.08,244,1712646000"; d="scan'208";a="19257232" Received: from orviesa009.jf.intel.com ([10.64.159.149]) by orvoesa106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2024 02:11:51 -0700 X-CSE-ConnectionGUID: VcXpBQoQSrWEh+o3IzW3FA== X-CSE-MsgGUID: dE7m1uW+Tp2647m8Wc9wmw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,244,1712646000"; d="scan'208";a="41260360" Received: from mshehzad-mobl.amr.corp.intel.com (HELO desk) ([10.209.21.13]) by orviesa009-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2024 02:11:51 -0700 Date: Mon, 17 Jun 2024 02:11:50 -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 Subject: [PATCH PATCH 5/9] x86/cpu: Name CPU matching macro more generically (and shorten) Message-ID: <20240617-add-cpu-type-v1-5-b88998c01e76@linux.intel.com> X-Mailer: b4 0.12.3 References: <20240617-add-cpu-type-v1-0-b88998c01e76@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: <20240617-add-cpu-type-v1-0-b88998c01e76@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 what it matches. For consistency, use this base macro to define X86_MATCH_VFM and friends. Signed-off-by: Pawan Gupta --- arch/x86/include/asm/cpu_device_id.h | 104 +++++++++++------------------------ 1 file changed, 31 insertions(+), 73 deletions(-) diff --git a/arch/x86/include/asm/cpu_device_id.h b/arch/x86/include/asm/cpu_device_id.h index b6325ee30871..6c8f4cf03cae 100644 --- a/arch/x86/include/asm/cpu_device_id.h +++ b/arch/x86/include/asm/cpu_device_id.h @@ -58,7 +58,7 @@ #define X86_STEPPINGS(mins, maxs) GENMASK(maxs, mins) /** - * 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 @@ -75,19 +75,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, \ @@ -107,13 +95,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. - * - * 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) +#define X86_MATCH_VENDOR_FAM_MODEL_FEATURE(vendor, family, model, feature, data) \ + X86_MATCH_CPU(X86_VENDOR_##vendor, family, model, X86_STEPPING_ANY, \ + feature, data) /** * X86_MATCH_VENDOR_FAM_FEATURE - Macro for matching vendor, family and CPU feature @@ -124,13 +109,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 @@ -140,12 +122,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 @@ -153,12 +133,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 @@ -169,13 +147,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 @@ -185,12 +160,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_INTEL_FAM6_MODEL - Match vendor INTEL, family 6 and model @@ -209,8 +182,8 @@ X86_MATCH_VENDOR_FAM_MODEL(INTEL, 6, INTEL_FAM6_##model, data) #define X86_MATCH_INTEL_FAM6_MODEL_STEPPINGS(model, steppings, data) \ - X86_MATCH_VENDOR_FAM_MODEL_STEPPINGS_FEATURE(INTEL, 6, INTEL_FAM6_##model, \ - steppings, X86_FEATURE_ANY, data) + X86_MATCH_CPU(X86_VENDOR_INTEL, 6, INTEL_FAM6_##model, \ + steppings, X86_FEATURE_ANY, data) /** * X86_MATCH_VFM - Match encoded vendor/family/model @@ -218,15 +191,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) /** * X86_MATCH_VFM_STEPPINGS - Match encoded vendor/family/model/stepping @@ -235,15 +203,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_STEPPINGS(vfm, steppings, data) \ - X86_MATCH_VENDORID_FAM_MODEL_STEPPINGS_FEATURE( \ - VFM_VENDOR(vfm), \ - VFM_FAMILY(vfm), \ - VFM_MODEL(vfm), \ - steppings, X86_FEATURE_ANY, data) +#define X86_MATCH_VFM_STEPPINGS(vfm, steppings, data) \ + X86_MATCH_CPU(VFM_VENDOR(vfm), VFM_FAMILY(vfm), VFM_MODEL(vfm), \ + steppings, X86_FEATURE_ANY, data) /** * X86_MATCH_VFM_FEATURE - Match encoded vendor/family/model/feature @@ -252,15 +215,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) /* * Match specific microcode revisions. From patchwork Mon Jun 17 09:12:01 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pawan Gupta X-Patchwork-Id: 805140 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (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 26AFB191485; Mon, 17 Jun 2024 09:12:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718615525; cv=none; b=JvTrbc/bxsz1LQZCQCYpbnoRrbAa82vETEpMuzQMFUtIDNBEI4nrrymaOpiCL7XHfgHWaZpz5lBU018pSTNd9LKdoudxJms8X0TBNkeWvrog3I4d+zYhtPgMmwgwDJB+3lo3tpCN8j5vg7Xz0VjWC1snhSpPSYdDvpQq1bKsEpA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718615525; c=relaxed/simple; bh=53iR0oJoFrK/mVOBbPtm8xBtCnOjOri/vZYCc4QFK40=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cp2qWde6s5KWw+FBcWh+9Y/Sqla/Em8X76nzsEM/OexUo8kpD9umwwIYj211zViQLkXsMLQJZxcbHEZZ+hj8bXurnBkjnhfXLnLpFQuLyRx0gT9j2qmjGzT1H0BPDVtWbJrAvspC3z0pAePJtTcZIDhvVg4MzOhSfLs+6ijjz1g= 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=DeRW3VhB; arc=none smtp.client-ip=198.175.65.10 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="DeRW3VhB" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1718615524; x=1750151524; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=53iR0oJoFrK/mVOBbPtm8xBtCnOjOri/vZYCc4QFK40=; b=DeRW3VhBaQIuoyS6pvbVooooOp6Go2cSGWu3x9pDAjDvrNhP6m+VshDz 2TdbNCaCtcQbTJhR7HhpGOCiw7bI8j+Po4WrrF/Em6UnnDmHpKQGPnDZQ iUdTLusWjJFg6T+ffhkg4109eRiMxkfxe4QcEfKj3r2ejXZRyrcYg86Qp vtaxJQqLG3fn+ytkqMjomgJQudgjG3Qyv7P993oX/Hav28IpeoJ18WRLG viPtKwUTS85y919cQC84Widr7o9FL6r627/18Zd+4OjY4mlwbr/7wFrnh vUTuMs3hQ4H1zh27sHBiKjgYoACNP1f8qh0dNziydj/5nIV9UKoVo3dR4 A==; X-CSE-ConnectionGUID: WD53lD0rTme+SA+ySgUPTQ== X-CSE-MsgGUID: SYgAFKySTMmsmGLAOk/Big== X-IronPort-AV: E=McAfee;i="6700,10204,11105"; a="32902571" X-IronPort-AV: E=Sophos;i="6.08,244,1712646000"; d="scan'208";a="32902571" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2024 02:12:04 -0700 X-CSE-ConnectionGUID: 2wQt2KXiS6qjeOzcmFUUeg== X-CSE-MsgGUID: s7sessOjR5ioPWz8WZE9ew== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,244,1712646000"; d="scan'208";a="72339312" Received: from mshehzad-mobl.amr.corp.intel.com (HELO desk) ([10.209.21.13]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2024 02:12:02 -0700 Date: Mon, 17 Jun 2024 02:12:01 -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 Subject: [PATCH PATCH 7/9] x86/cpu: Update x86_match_cpu() to also use cpu-type Message-ID: <20240617-add-cpu-type-v1-7-b88998c01e76@linux.intel.com> X-Mailer: b4 0.12.3 References: <20240617-add-cpu-type-v1-0-b88998c01e76@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: <20240617-add-cpu-type-v1-0-b88998c01e76@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 Signed-off-by: Pawan Gupta --- arch/x86/kernel/cpu/match.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/arch/x86/kernel/cpu/match.c b/arch/x86/kernel/cpu/match.c index 8e7de733320a..ca15e74596d7 100644 --- a/arch/x86/kernel/cpu/match.c +++ b/arch/x86/kernel/cpu/match.c @@ -5,6 +5,26 @@ #include #include +/** + * x86_match_cpu - helper function to match the cpu-type for a single + * entry in the x86_cpu_id table. + * @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_cpu_type(struct cpuinfo_x86 *c, const struct x86_cpu_id *m) +{ + if (m->cpu_type == X86_CPU_TYPE_ANY) + return true; + + /* Hybrid CPUs are special, they are assumed to match all cpu-types */ + if (boot_cpu_has(X86_FEATURE_HYBRID_CPU)) + return true; + + return c->topo.cpu_type == m->cpu_type; +} + /** * x86_match_cpu - match current CPU again an array of x86_cpu_ids * @match: Pointer to array of x86_cpu_ids. Last entry terminated with @@ -50,6 +70,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_cpu_type(c, m)) + continue; return m; } return NULL; From patchwork Mon Jun 17 09:12:14 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pawan Gupta X-Patchwork-Id: 805139 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) (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 76098194AF2; Mon, 17 Jun 2024 09:12:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.10 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718615537; cv=none; b=Ori/1gMtx5paxjX7qfQmW1KZfKi/3vCg+bnUv5Pk06wa9hpRvyLZBdns45RJ/x0+rdAWvkdXqwOdpW6hr4S7Qo0eDzKs0TQ4FmdvK4STAzxUVz27nwCnNWL1Rn1hPrq6TRRAjy152sxIFOJyEnKVo2GbF0RWu+AexkFHc1nOxsk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718615537; c=relaxed/simple; bh=os5ebhwol7XkQChRWi2jxxkCPHPBHfQ9E9+GSsyzYjY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=G/netxLngg0p7CSaMctfWoCZjFxO4RM3KUZLSoDlJxxMImPZb140a5vKDZuQ3ybjRPxDdtWVVQpTiPRODqVKXxXwIKqFbLqVPW5eZCtNVUhYZjmDUFCEKynApZM3VbKYV1RJRxPMLT73aHwO9fmQ4oItZTzntJ7wQuDJYYbFTV4= 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=QOkF5Alu; arc=none smtp.client-ip=198.175.65.10 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="QOkF5Alu" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1718615537; x=1750151537; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=os5ebhwol7XkQChRWi2jxxkCPHPBHfQ9E9+GSsyzYjY=; b=QOkF5AluCywVhWKtzRTUfgiI7N3dhycUjwtoLrY6/7CBjwKJ2GbC1jBX 17cZNmJGQNpfKsAYnjU5RsL5dxu0+tUyEUrmQzgGDOUrb84OGH15dDAO+ QIuoakUOIP6Uev7NnnWiWPY5fIJV/JjbrqEeqn/EW4cLcH88XHJJyg2sC Y145ClpL4ab9VmY0PI7oU6PWXvSlBGDN/wCtpyvGd3mgKdn1Q6/qewKXh tdhqQNWZtEEHtHOGOFYY6Dq3X2t41wdJW3xLzzIY+wzPZkwJL0DQGt75q pc3h8i1deZyWeIJ8zyyEGg0fZTBsr3fEdSrpoVMLxcKAhwGYonepWzCen g==; X-CSE-ConnectionGUID: flpYCcYMR2SrwlsjdRG8yQ== X-CSE-MsgGUID: qUQ69PZjQ6WDRkyjZUnRBg== X-IronPort-AV: E=McAfee;i="6700,10204,11105"; a="32902618" X-IronPort-AV: E=Sophos;i="6.08,244,1712646000"; d="scan'208";a="32902618" Received: from fmviesa001.fm.intel.com ([10.60.135.141]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2024 02:12:16 -0700 X-CSE-ConnectionGUID: recinEz5RX2yfoeqD3qSuw== X-CSE-MsgGUID: dtVnO4EtRe+etUL+7QEflg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,244,1712646000"; d="scan'208";a="72339686" Received: from mshehzad-mobl.amr.corp.intel.com (HELO desk) ([10.209.21.13]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Jun 2024 02:12:15 -0700 Date: Mon, 17 Jun 2024 02:12:14 -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 Subject: [PATCH PATCH 9/9] x86/rfds: Exclude P-only parts from the RFDS affected list Message-ID: <20240617-add-cpu-type-v1-9-b88998c01e76@linux.intel.com> X-Mailer: b4 0.12.3 References: <20240617-add-cpu-type-v1-0-b88998c01e76@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: <20240617-add-cpu-type-v1-0-b88998c01e76@linux.intel.com> RFDS only affects Atom parts. Vendor/Family/Model matching in the affected processor table makes Alderlake and Raptorlake P-only parts affected (which are not affected in reality). This is because the affected hybrid and E-only parts have the same Family/Model as the unaffected P-only parts. Match CPU-type as Atom to exclude P-only parts as RFDS affected. Note, a guest with the same Family/Model as the affected part may not have leaf 1A enumerated to know its CPU-type, but it should not be a problem as guest's Family/Model can anyways be inaccurate. Moreover, RFDS_NO or RFDS_CLEAR enumeration by the VMM decides the affected status of the guest. 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 7e3b09b0f82c..73ec66321758 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1209,6 +1209,9 @@ static const __initconst struct x86_cpu_id cpu_vuln_whitelist[] = { #define VULNBL_INTEL_STEPPINGS(vfm, steppings, issues) \ X86_MATCH_VFM_STEPPINGS(INTEL_##vfm, steppings, issues) +#define VULNBL_INTEL_CPU_TYPE(vfm, cpu_type, issues) \ + X86_MATCH_VFM_CPU_TYPE(INTEL_##vfm, cpu_type, issues) + #define VULNBL_AMD(family, blacklist) \ VULNBL(AMD, family, X86_MODEL_ANY, blacklist) @@ -1255,9 +1258,7 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = { VULNBL_INTEL(TIGERLAKE, GDS), VULNBL_INTEL(LAKEFIELD, MMIO | MMIO_SBDS | RETBLEED), VULNBL_INTEL(ROCKETLAKE, MMIO | RETBLEED | GDS), - VULNBL_INTEL(ALDERLAKE, RFDS), VULNBL_INTEL(ALDERLAKE_L, RFDS), - VULNBL_INTEL(RAPTORLAKE, RFDS), VULNBL_INTEL(RAPTORLAKE_P, RFDS), VULNBL_INTEL(RAPTORLAKE_S, RFDS), VULNBL_INTEL(ATOM_GRACEMONT, RFDS), @@ -1271,6 +1272,8 @@ static const struct x86_cpu_id cpu_vuln_blacklist[] __initconst = { /* Match more than Vendor/Family/Model */ VULNBL_INTEL_STEPPINGS(COMETLAKE_L, X86_STEPPINGS(0x0, 0x0), MMIO | RETBLEED), VULNBL_INTEL (COMETLAKE_L, MMIO | MMIO_SBDS | RETBLEED | GDS), + VULNBL_INTEL_CPU_TYPE (RAPTORLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS), + VULNBL_INTEL_CPU_TYPE (ALDERLAKE, X86_CPU_TYPE_INTEL_ATOM, RFDS), VULNBL_AMD(0x15, RETBLEED), VULNBL_AMD(0x16, RETBLEED),