From patchwork Wed Jun 22 14:48:17 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxim Levitsky X-Patchwork-Id: 584752 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C93B8C43334 for ; Wed, 22 Jun 2022 14:49:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357478AbiFVOtG (ORCPT ); Wed, 22 Jun 2022 10:49:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46866 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358107AbiFVOtE (ORCPT ); Wed, 22 Jun 2022 10:49:04 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4C53B3DDD2 for ; Wed, 22 Jun 2022 07:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655909339; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=JV9YRdtqoo7wzkDPDGDuYdQDwku8zHdZp+0Mbg9ps38=; b=V2L1PMAoCL5mmB59k6U2+v/dv7zW6ReuX9ctia6Tkv1TD036f/IWmQZOlhWkCkJrW1uTJP YealInq9Nb6Pp35aC/XEjJp9TO1X3WnZeXxfaTUcNkWyY2sQF9XM0iBQO0a63nfig47nS3 TyTFVTOLW1W4JCSdfALc5vHFGEWCpKc= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-64-GvR57FqhPSOhQOOsE3g4wg-1; Wed, 22 Jun 2022 10:48:53 -0400 X-MC-Unique: GvR57FqhPSOhQOOsE3g4wg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3C9E71DC245B; Wed, 22 Jun 2022 14:48:34 +0000 (UTC) Received: from localhost.localdomain (unknown [10.40.194.180]) by smtp.corp.redhat.com (Postfix) with ESMTP id C3A2F404E4DF; Wed, 22 Jun 2022 14:48:28 +0000 (UTC) From: Maxim Levitsky To: linux-kernel@vger.kernel.org Cc: "Chang S. Bae" , Jiri Olsa , linux-perf-users@vger.kernel.org, Peter Zijlstra , "H. Peter Anvin" , "David S. Miller" , Borislav Petkov , Kees Cook , Mark Rutland , Alexander Shishkin , Namhyung Kim , Tim Chen , Maxim Levitsky , Pawan Gupta , Herbert Xu , Dave Hansen , x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)), Jane Malalane , Tony Luck , Ingo Molnar , Thomas Gleixner , Arnaldo Carvalho de Melo , linux-crypto@vger.kernel.org (open list:CRYPTO API), Paolo Bonzini Subject: [PATCH 1/4] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap Date: Wed, 22 Jun 2022 17:48:17 +0300 Message-Id: <20220622144820.751402-2-mlevitsk@redhat.com> In-Reply-To: <20220622144820.751402-1-mlevitsk@redhat.com> References: <20220622144820.751402-1-mlevitsk@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org clear_cpu_cap(&boot_cpu_data) is very similar to setup_clear_cpu_cap except that the latter also sets a bit in 'cpu_caps_cleared' which later clears the same cap in secondary cpus, which is likely what is meant here. Signed-off-by: Maxim Levitsky --- arch/x86/events/intel/lbr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c index 13179f31fe10fa..b08715172309a7 100644 --- a/arch/x86/events/intel/lbr.c +++ b/arch/x86/events/intel/lbr.c @@ -1860,7 +1860,7 @@ void __init intel_pmu_arch_lbr_init(void) return; clear_arch_lbr: - clear_cpu_cap(&boot_cpu_data, X86_FEATURE_ARCH_LBR); + setup_clear_cpu_cap(X86_FEATURE_ARCH_LBR); } /** From patchwork Wed Jun 22 14:48:18 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxim Levitsky X-Patchwork-Id: 583963 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9E95EC43334 for ; Wed, 22 Jun 2022 14:49:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358420AbiFVOtM (ORCPT ); Wed, 22 Jun 2022 10:49:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358513AbiFVOtE (ORCPT ); Wed, 22 Jun 2022 10:49:04 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7E4713DDF9 for ; Wed, 22 Jun 2022 07:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655909342; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=XCWooTms+wWlHXZcDu8ZPg89E6H/2XmTErhXmxcvgaE=; b=AqYIm6MfW97EttoMCBJZwhtag9T+nkbiYHuJ++lYp4Peg88OrWHPIYHMgtvi35Lng3uPDe uMBq+QKG+i55pFaxhkCLuMk+vVlq6mGWfJcOPWY/2NeNgvFulXmn32lg3gawXhatZw87hS R2c76PIYb4fSNstWfDoxysMogcGC5J0= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-220-brYIksGeNkyLtuH1ievjYA-1; Wed, 22 Jun 2022 10:48:57 -0400 X-MC-Unique: brYIksGeNkyLtuH1ievjYA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id BCECA2A2AD44; Wed, 22 Jun 2022 14:48:39 +0000 (UTC) Received: from localhost.localdomain (unknown [10.40.194.180]) by smtp.corp.redhat.com (Postfix) with ESMTP id 96EDC40E80FF; Wed, 22 Jun 2022 14:48:34 +0000 (UTC) From: Maxim Levitsky To: linux-kernel@vger.kernel.org Cc: "Chang S. Bae" , Jiri Olsa , linux-perf-users@vger.kernel.org, Peter Zijlstra , "H. Peter Anvin" , "David S. Miller" , Borislav Petkov , Kees Cook , Mark Rutland , Alexander Shishkin , Namhyung Kim , Tim Chen , Maxim Levitsky , Pawan Gupta , Herbert Xu , Dave Hansen , x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)), Jane Malalane , Tony Luck , Ingo Molnar , Thomas Gleixner , Arnaldo Carvalho de Melo , linux-crypto@vger.kernel.org (open list:CRYPTO API), Paolo Bonzini Subject: [PATCH 2/4] x86/cpuid: refactor setup_clear_cpu_cap/clear_feature Date: Wed, 22 Jun 2022 17:48:18 +0300 Message-Id: <20220622144820.751402-3-mlevitsk@redhat.com> In-Reply-To: <20220622144820.751402-1-mlevitsk@redhat.com> References: <20220622144820.751402-1-mlevitsk@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Simplify the code a bit by always passing &boot_cpu_data in case the setup_clear_cpu_cap was called. Also unify clear_cpu_cap and do_clear_cpu_cap. Signed-off-by: Maxim Levitsky --- arch/x86/kernel/cpu/cpuid-deps.c | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-) diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index c881bcafba7d70..d6777d07ba3302 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -88,18 +88,16 @@ static inline void clear_feature(struct cpuinfo_x86 *c, unsigned int feature) * rest of the cpufeature code uses atomics as well, so keep it for * consistency. Cleanup all of it separately. */ - if (!c) { - clear_cpu_cap(&boot_cpu_data, feature); + clear_bit(feature, (unsigned long *)c->x86_capability); + + if (c == &boot_cpu_data) set_bit(feature, (unsigned long *)cpu_caps_cleared); - } else { - clear_bit(feature, (unsigned long *)c->x86_capability); - } } /* Take the capabilities and the BUG bits into account */ #define MAX_FEATURE_BITS ((NCAPINTS + NBUGINTS) * sizeof(u32) * 8) -static void do_clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature) +void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature) { DECLARE_BITMAP(disable, MAX_FEATURE_BITS); const struct cpuid_dep *d; @@ -129,12 +127,7 @@ static void do_clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature) } while (changed); } -void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature) -{ - do_clear_cpu_cap(c, feature); -} - void setup_clear_cpu_cap(unsigned int feature) { - do_clear_cpu_cap(NULL, feature); + clear_cpu_cap(&boot_cpu_data, feature); } From patchwork Wed Jun 22 14:48:19 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxim Levitsky X-Patchwork-Id: 584751 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18AB7CCA483 for ; Wed, 22 Jun 2022 14:49:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358173AbiFVOtL (ORCPT ); Wed, 22 Jun 2022 10:49:11 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47044 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358381AbiFVOtE (ORCPT ); Wed, 22 Jun 2022 10:49:04 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 790E83DDF0 for ; Wed, 22 Jun 2022 07:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655909341; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=EfBoGV8G1t/ZFoRqhI564VYHfItzSstPW0YccRoMmqE=; b=MFyoSGIZW7rh72H34cf3+9tSYIC0Bpj+ma/9h1UCmZMXkrVT20zJpu6K5NJqu1icsvyMNj ylcEnjBrffI44jfFYZ/MvHAVsNQkd88NJNnFDrM0oASLjv1lgXPilMuoep3gvQzeTlVLZd yGFy5pOHKwR3BbbmT7cNPA1N6Osmgo4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-323-q1hoiWDCP5afXOn50jXiQA-1; Wed, 22 Jun 2022 10:48:58 -0400 X-MC-Unique: q1hoiWDCP5afXOn50jXiQA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3FB1482406B; Wed, 22 Jun 2022 14:48:45 +0000 (UTC) Received: from localhost.localdomain (unknown [10.40.194.180]) by smtp.corp.redhat.com (Postfix) with ESMTP id 2199240D2962; Wed, 22 Jun 2022 14:48:39 +0000 (UTC) From: Maxim Levitsky To: linux-kernel@vger.kernel.org Cc: "Chang S. Bae" , Jiri Olsa , linux-perf-users@vger.kernel.org, Peter Zijlstra , "H. Peter Anvin" , "David S. Miller" , Borislav Petkov , Kees Cook , Mark Rutland , Alexander Shishkin , Namhyung Kim , Tim Chen , Maxim Levitsky , Pawan Gupta , Herbert Xu , Dave Hansen , x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)), Jane Malalane , Tony Luck , Ingo Molnar , Thomas Gleixner , Arnaldo Carvalho de Melo , linux-crypto@vger.kernel.org (open list:CRYPTO API), Paolo Bonzini Subject: [PATCH 3/4] x86/cpuid: move filter_cpuid_features to cpuid-deps.c Date: Wed, 22 Jun 2022 17:48:19 +0300 Message-Id: <20220622144820.751402-4-mlevitsk@redhat.com> In-Reply-To: <20220622144820.751402-1-mlevitsk@redhat.com> References: <20220622144820.751402-1-mlevitsk@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org No functional change intended. Signed-off-by: Maxim Levitsky --- arch/x86/include/asm/cpufeature.h | 1 + arch/x86/kernel/cpu/common.c | 46 ----------------------------- arch/x86/kernel/cpu/cpuid-deps.c | 48 +++++++++++++++++++++++++++++++ 3 files changed, 49 insertions(+), 46 deletions(-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index ea34cc31b0474f..3eb5fe0d654e63 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -147,6 +147,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32]; extern void setup_clear_cpu_cap(unsigned int bit); extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit); +extern void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn); #define setup_force_cpu_cap(bit) do { \ set_cpu_cap(&boot_cpu_data, bit); \ diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 4730b0a58f24a5..4cc79971d2d847 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -620,52 +620,6 @@ __noendbr void cet_disable(void) wrmsrl(MSR_IA32_S_CET, 0); } -/* - * Some CPU features depend on higher CPUID levels, which may not always - * be available due to CPUID level capping or broken virtualization - * software. Add those features to this table to auto-disable them. - */ -struct cpuid_dependent_feature { - u32 feature; - u32 level; -}; - -static const struct cpuid_dependent_feature -cpuid_dependent_features[] = { - { X86_FEATURE_MWAIT, 0x00000005 }, - { X86_FEATURE_DCA, 0x00000009 }, - { X86_FEATURE_XSAVE, 0x0000000d }, - { 0, 0 } -}; - -static void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn) -{ - const struct cpuid_dependent_feature *df; - - for (df = cpuid_dependent_features; df->feature; df++) { - - if (!cpu_has(c, df->feature)) - continue; - /* - * Note: cpuid_level is set to -1 if unavailable, but - * extended_extended_level is set to 0 if unavailable - * and the legitimate extended levels are all negative - * when signed; hence the weird messing around with - * signs here... - */ - if (!((s32)df->level < 0 ? - (u32)df->level > (u32)c->extended_cpuid_level : - (s32)df->level > (s32)c->cpuid_level)) - continue; - - clear_cpu_cap(c, df->feature); - if (!warn) - continue; - - pr_warn("CPU: CPU feature " X86_CAP_FMT " disabled, no CPUID level 0x%x\n", - x86_cap_flag(df->feature), df->level); - } -} /* * Naming convention should be: [()] diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index d6777d07ba3302..bcb091d02a754b 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -131,3 +131,51 @@ void setup_clear_cpu_cap(unsigned int feature) { clear_cpu_cap(&boot_cpu_data, feature); } + + +/* + * Some CPU features depend on higher CPUID levels, which may not always + * be available due to CPUID level capping or broken virtualization + * software. Add those features to this table to auto-disable them. + */ +struct cpuid_dependent_feature { + u32 feature; + u32 level; +}; + +static const struct cpuid_dependent_feature +cpuid_dependent_features[] = { + { X86_FEATURE_MWAIT, 0x00000005 }, + { X86_FEATURE_DCA, 0x00000009 }, + { X86_FEATURE_XSAVE, 0x0000000d }, + { 0, 0 } +}; + +void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn) +{ + const struct cpuid_dependent_feature *df; + + for (df = cpuid_dependent_features; df->feature; df++) { + + if (!cpu_has(c, df->feature)) + continue; + /* + * Note: cpuid_level is set to -1 if unavailable, but + * extended_extended_level is set to 0 if unavailable + * and the legitimate extended levels are all negative + * when signed; hence the weird messing around with + * signs here... + */ + if (!((s32)df->level < 0 ? + (u32)df->level > (u32)c->extended_cpuid_level : + (s32)df->level > (s32)c->cpuid_level)) + continue; + + clear_cpu_cap(c, df->feature); + if (!warn) + continue; + + pr_warn("CPU: CPU feature " X86_CAP_FMT " disabled, no CPUID level 0x%x\n", + x86_cap_flag(df->feature), df->level); + } +} From patchwork Wed Jun 22 14:48:20 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxim Levitsky X-Patchwork-Id: 583964 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8C3F5C43334 for ; Wed, 22 Jun 2022 14:49:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1357560AbiFVOtJ (ORCPT ); Wed, 22 Jun 2022 10:49:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47078 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1358184AbiFVOtE (ORCPT ); Wed, 22 Jun 2022 10:49:04 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id DE16F3DDE6 for ; Wed, 22 Jun 2022 07:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1655909340; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4hYutT6A0gBfkQr0X8J4zcR1vTCradKixIqqKEZ5f2E=; b=Ks0U9jGpvN7o+bNNfIAnM/Km4cA0wlSE6OPKaHxoNIOMDUc9+yIAZWBFQe6deJU5FtTXgK 52muNQVdGY6NkRMw8SYNT/wfZqMniKwEW5ULUVQYTO0w2vUufrW5UaOssq/eicoftm8TD9 mCrdmGGO45K3FJHzRJ3I9nIfiEjmsJQ= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-244-iwwwGXe1MYCm2IvYuoTHzg-1; Wed, 22 Jun 2022 10:48:58 -0400 X-MC-Unique: iwwwGXe1MYCm2IvYuoTHzg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id B87E328049E5; Wed, 22 Jun 2022 14:48:50 +0000 (UTC) Received: from localhost.localdomain (unknown [10.40.194.180]) by smtp.corp.redhat.com (Postfix) with ESMTP id 99A0E40C1421; Wed, 22 Jun 2022 14:48:45 +0000 (UTC) From: Maxim Levitsky To: linux-kernel@vger.kernel.org Cc: "Chang S. Bae" , Jiri Olsa , linux-perf-users@vger.kernel.org, Peter Zijlstra , "H. Peter Anvin" , "David S. Miller" , Borislav Petkov , Kees Cook , Mark Rutland , Alexander Shishkin , Namhyung Kim , Tim Chen , Maxim Levitsky , Pawan Gupta , Herbert Xu , Dave Hansen , x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)), Jane Malalane , Tony Luck , Ingo Molnar , Thomas Gleixner , Arnaldo Carvalho de Melo , linux-crypto@vger.kernel.org (open list:CRYPTO API), Paolo Bonzini Subject: [PATCH 4/4] x86/cpuid: check for dependencies violations in CPUID and attempt to fix them Date: Wed, 22 Jun 2022 17:48:20 +0300 Message-Id: <20220622144820.751402-5-mlevitsk@redhat.com> In-Reply-To: <20220622144820.751402-1-mlevitsk@redhat.com> References: <20220622144820.751402-1-mlevitsk@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Due to configuration bugs, sometimes a CPU feature is disabled in CPUID, but not features that depend on it. While the above is not supported, the kernel should try to not crash, and clearing the dependent cpu caps is the best way to do it. Signed-off-by: Maxim Levitsky --- arch/x86/kernel/cpu/common.c | 4 ++-- arch/x86/kernel/cpu/cpuid-deps.c | 27 +++++++++++++++++++++++++-- 2 files changed, 27 insertions(+), 4 deletions(-) diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c index 4cc79971d2d847..c83a8f447d6aed 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1469,7 +1469,7 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c) this_cpu->c_early_init(c); c->cpu_index = 0; - filter_cpuid_features(c, false); + filter_cpuid_features(c, true); if (this_cpu->c_bsp_init) this_cpu->c_bsp_init(c); @@ -1757,7 +1757,7 @@ static void identify_cpu(struct cpuinfo_x86 *c) */ /* Filter out anything that depends on CPUID levels we don't have */ - filter_cpuid_features(c, true); + filter_cpuid_features(c, false); /* If the model name is still unset, do table lookup. */ if (!c->x86_model_id[0]) { diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index bcb091d02a754b..6d9c0e39851805 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -94,6 +94,11 @@ static inline void clear_feature(struct cpuinfo_x86 *c, unsigned int feature) set_bit(feature, (unsigned long *)cpu_caps_cleared); } +static inline bool test_feature(struct cpuinfo_x86 *c, unsigned int feature) +{ + return test_bit(feature, (unsigned long *)c->x86_capability); +} + /* Take the capabilities and the BUG bits into account */ #define MAX_FEATURE_BITS ((NCAPINTS + NBUGINTS) * sizeof(u32) * 8) @@ -127,6 +132,7 @@ void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int feature) } while (changed); } + void setup_clear_cpu_cap(unsigned int feature) { clear_cpu_cap(&boot_cpu_data, feature); @@ -137,6 +143,10 @@ void setup_clear_cpu_cap(unsigned int feature) * Some CPU features depend on higher CPUID levels, which may not always * be available due to CPUID level capping or broken virtualization * software. Add those features to this table to auto-disable them. + * + * Also due to configuration bugs, some CPUID features might be present + * while CPUID features that they depend on are not present, + * e.g a AVX2 present but AVX is not present. */ struct cpuid_dependent_feature { u32 feature; @@ -151,9 +161,10 @@ cpuid_dependent_features[] = { { 0, 0 } }; -void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn) +void filter_cpuid_features(struct cpuinfo_x86 *c, bool early) { const struct cpuid_dependent_feature *df; + const struct cpuid_dep *d; for (df = cpuid_dependent_features; df->feature; df++) { @@ -172,10 +183,22 @@ void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn) continue; clear_cpu_cap(c, df->feature); - if (!warn) + if (early) continue; pr_warn("CPU: CPU feature " X86_CAP_FMT " disabled, no CPUID level 0x%x\n", x86_cap_flag(df->feature), df->level); } + + for (d = cpuid_deps; d->feature; d++) { + + if (!test_feature(c, d->feature) || test_feature(c, d->depends)) + continue; + + clear_feature(c, d->feature); + + pr_warn("CPU: CPU feature " X86_CAP_FMT " disabled, because it depends on " + X86_CAP_FMT " which is not supported in CPUID\n", + x86_cap_flag(d->feature), x86_cap_flag(d->depends)); + } }