From patchwork Mon Jul 18 14:11: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: 592208 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 1B643CCA479 for ; Mon, 18 Jul 2022 14:11:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235727AbiGROLn (ORCPT ); Mon, 18 Jul 2022 10:11:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36814 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235285AbiGROLl (ORCPT ); Mon, 18 Jul 2022 10:11:41 -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 CCAE7275C1 for ; Mon, 18 Jul 2022 07:11:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658153500; 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=0PgYUbpcI18aPSDLfXO0VvnbczjLoh+Trj4I+dch4ZU=; b=IsqwnO2NdWg7HSVOzuNhVEbu6IkOi9fMZ3jzxadzhimTIP6FfTwI+I2bdUz5IzKQxRag/Y IJ+/a2ZFuLnwr6DX5tQnoY8p0ErejM0g8U3DeEM/EadMJU5eGeA3ypjDl1slTofaF2+NS/ YPxZYWCyij1t4EI/c7YWYCll3SasnWY= 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-193-ZvEW642ONcCrVnYdmGuw2Q-1; Mon, 18 Jul 2022 10:11:36 -0400 X-MC-Unique: ZvEW642ONcCrVnYdmGuw2Q-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 33502101A588; Mon, 18 Jul 2022 14:11:35 +0000 (UTC) Received: from amdlaptop.tlv.redhat.com (dhcp-4-238.tlv.redhat.com [10.35.4.238]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8EB232026D2D; Mon, 18 Jul 2022 14:11:30 +0000 (UTC) From: Maxim Levitsky To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Pawan Gupta , Ingo Molnar , Josh Poimboeuf , Namhyung Kim , Tony Luck , Paolo Bonzini , "H. Peter Anvin" , Arnaldo Carvalho de Melo , Thomas Gleixner , Alexander Shishkin , Tim Chen , Borislav Petkov , "David S. Miller" , Dave Hansen , "Chang S. Bae" , Jane Malalane , Kees Cook , Kan Liang , Peter Zijlstra , Maxim Levitsky , x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)), Herbert Xu , Jiri Olsa , Mark Rutland , linux-perf-users@vger.kernel.org, linux-crypto@vger.kernel.org (open list:CRYPTO API) Subject: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap Date: Mon, 18 Jul 2022 17:11:19 +0300 Message-Id: <20220718141123.136106-2-mlevitsk@redhat.com> In-Reply-To: <20220718141123.136106-1-mlevitsk@redhat.com> References: <20220718141123.136106-1-mlevitsk@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 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. Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR") Reviewed-by: Kan Liang 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 Mon Jul 18 14:11: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: 591532 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 79C6AC43334 for ; Mon, 18 Jul 2022 14:11:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235741AbiGROLz (ORCPT ); Mon, 18 Jul 2022 10:11:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37002 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235071AbiGROLy (ORCPT ); Mon, 18 Jul 2022 10:11:54 -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 2A8312714C for ; Mon, 18 Jul 2022 07:11:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658153512; 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=w5ar1xL/lWu4+LzORYC79cebbS3mhMxSowTJXzIDy14=; b=Oy0g75aHSEljcev3+J0Dfex68Bxt0Y7k9iHue9UyhauJqYE1R1U4jASc0ycO7zzmSfua+0 cnWl+/5snznE6q+B43Y0vx9KWi5FZ/YdEnHe7yGGsd6mUepcBSAohH3lcs6gojp1UQgFiW pDhH3edQKgyHiXxS0vEj3duq4WSGvQ0= 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-62-F11jd_UNMn6FzKPX6SELGw-1; Mon, 18 Jul 2022 10:11:42 -0400 X-MC-Unique: F11jd_UNMn6FzKPX6SELGw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3250096AC62; Mon, 18 Jul 2022 14:11:40 +0000 (UTC) Received: from amdlaptop.tlv.redhat.com (dhcp-4-238.tlv.redhat.com [10.35.4.238]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7E7D92026D64; Mon, 18 Jul 2022 14:11:35 +0000 (UTC) From: Maxim Levitsky To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Pawan Gupta , Ingo Molnar , Josh Poimboeuf , Namhyung Kim , Tony Luck , Paolo Bonzini , "H. Peter Anvin" , Arnaldo Carvalho de Melo , Thomas Gleixner , Alexander Shishkin , Tim Chen , Borislav Petkov , "David S. Miller" , Dave Hansen , "Chang S. Bae" , Jane Malalane , Kees Cook , Kan Liang , Peter Zijlstra , Maxim Levitsky , x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)), Herbert Xu , Jiri Olsa , Mark Rutland , linux-perf-users@vger.kernel.org, linux-crypto@vger.kernel.org (open list:CRYPTO API) Subject: [PATCH v2 2/5] x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap() Date: Mon, 18 Jul 2022 17:11:20 +0300 Message-Id: <20220718141123.136106-3-mlevitsk@redhat.com> In-Reply-To: <20220718141123.136106-1-mlevitsk@redhat.com> References: <20220718141123.136106-1-mlevitsk@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Currently setup_clear_cpu_cap passes NULL 'struct cpuinfo_x86*' to clear_cpu_cap to indicate that capability should be cleared from boot_cpu_data. Later that is used in clear_feature to do recursive call to clear_cpu_cap together with clearing the feature bit from 'cpu_caps_cleared' Remove that code and just call the do_clear_cpu_cap on boot_cpu_data directly from the setup_clear_cpu_cap. The only functional change this introduces is that now calling clear_cpu_cap explicitly on boot_cpu_data also sets the bits in cpu_caps_cleared, which is the only thing that makes sense anyway. All callers of both functions were checked for this and fixed. 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 Mon Jul 18 14:11:21 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxim Levitsky X-Patchwork-Id: 592207 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 DCB2CC433EF for ; Mon, 18 Jul 2022 14:11:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235728AbiGROL4 (ORCPT ); Mon, 18 Jul 2022 10:11:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37032 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235071AbiGROLz (ORCPT ); Mon, 18 Jul 2022 10:11:55 -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 CED9C2714C for ; Mon, 18 Jul 2022 07:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658153514; 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=WQ28KCG8qrZVHeMH3WgWsVAsqXW66sq9MXnU4h146Bs=; b=Cr1P48iiCXZRphBXZ+cqMdDW+pmgdqYbT9jmpPTSpT8dhoevF8IdFGGDj+TkHWotdsHGFH Vi1KSyGmFHnmAAhzxOhSWF88mt0hvNjr6/zE2t0C1nEY4TphJer7QpVMB0GdcjTFX+zr4A jJtWWuGY2vXbNqohYe3S9rRCMKTHaBU= 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-638-Mw1UrJkLOfKZHkMeNfQTmg-1; Mon, 18 Jul 2022 10:11:46 -0400 X-MC-Unique: Mw1UrJkLOfKZHkMeNfQTmg-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4EC0529ABA0B; Mon, 18 Jul 2022 14:11:45 +0000 (UTC) Received: from amdlaptop.tlv.redhat.com (dhcp-4-238.tlv.redhat.com [10.35.4.238]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7DE182026D64; Mon, 18 Jul 2022 14:11:40 +0000 (UTC) From: Maxim Levitsky To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Pawan Gupta , Ingo Molnar , Josh Poimboeuf , Namhyung Kim , Tony Luck , Paolo Bonzini , "H. Peter Anvin" , Arnaldo Carvalho de Melo , Thomas Gleixner , Alexander Shishkin , Tim Chen , Borislav Petkov , "David S. Miller" , Dave Hansen , "Chang S. Bae" , Jane Malalane , Kees Cook , Kan Liang , Peter Zijlstra , Maxim Levitsky , x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)), Herbert Xu , Jiri Olsa , Mark Rutland , linux-perf-users@vger.kernel.org, linux-crypto@vger.kernel.org (open list:CRYPTO API) Subject: [PATCH v2 3/5] x86/cpuid: move filter_cpuid_features to cpuid-deps.c Date: Mon, 18 Jul 2022 17:11:21 +0300 Message-Id: <20220718141123.136106-4-mlevitsk@redhat.com> In-Reply-To: <20220718141123.136106-1-mlevitsk@redhat.com> References: <20220718141123.136106-1-mlevitsk@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org filter_cpuid_features performs a sanity check on CPU/hypervisor provided CPUID in regard to having all required leaves which some CPUID feature bits require. Soon this sanity check will be extended to also disable CPUID features which were erronsly enabled in CPUID and depend on features that are marked as disabled in the CPUID. It thus makes sense to have both checks in one file. No functional change intended. Signed-off-by: Maxim Levitsky --- arch/x86/include/asm/cpufeature.h | 1 + arch/x86/kernel/cpu/common.c | 47 ------------------------------- arch/x86/kernel/cpu/cpuid-deps.c | 47 +++++++++++++++++++++++++++++++ 3 files changed, 48 insertions(+), 47 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 736262a76a12b7..beaea42c1b47e1 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -620,53 +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: [()] * This table only is used unless init_() below doesn't set it; diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index d6777d07ba3302..306f285844aedc 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -131,3 +131,50 @@ 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 Mon Jul 18 14:11:22 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxim Levitsky X-Patchwork-Id: 591531 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 5EAA5C433EF for ; Mon, 18 Jul 2022 14:12:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234539AbiGROMF (ORCPT ); Mon, 18 Jul 2022 10:12:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37064 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235758AbiGROL5 (ORCPT ); Mon, 18 Jul 2022 10:11:57 -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 E480F27170 for ; Mon, 18 Jul 2022 07:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658153516; 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=T8Z2XJYyS9V8KZ6uFYvGdAv2HuDcr4S84Jovz3Opi0M=; b=BICV18t+I2rVsxoZxbZyZOSo9S5WoBPRjNWbAtsP1yoADUQ60aKfxATOV/szQ83ojLjiTf VffIW898+7k+GwAHW5GPXUi+GdIFpLiWiiFb2XqWoZzpLqScho05LHE//gA0IF+BqLrREp tCa/RzW2BuUDT0/DMzQm93tcV6Kc5Z8= 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-63-Rqy0FaU5MVW-WcZIbWk9Kw-1; Mon, 18 Jul 2022 10:11:52 -0400 X-MC-Unique: Rqy0FaU5MVW-WcZIbWk9Kw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A17003C02B86; Mon, 18 Jul 2022 14:11:50 +0000 (UTC) Received: from amdlaptop.tlv.redhat.com (dhcp-4-238.tlv.redhat.com [10.35.4.238]) by smtp.corp.redhat.com (Postfix) with ESMTP id A528D2026D64; Mon, 18 Jul 2022 14:11:45 +0000 (UTC) From: Maxim Levitsky To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Pawan Gupta , Ingo Molnar , Josh Poimboeuf , Namhyung Kim , Tony Luck , Paolo Bonzini , "H. Peter Anvin" , Arnaldo Carvalho de Melo , Thomas Gleixner , Alexander Shishkin , Tim Chen , Borislav Petkov , "David S. Miller" , Dave Hansen , "Chang S. Bae" , Jane Malalane , Kees Cook , Kan Liang , Peter Zijlstra , Maxim Levitsky , x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)), Herbert Xu , Jiri Olsa , Mark Rutland , linux-perf-users@vger.kernel.org, linux-crypto@vger.kernel.org (open list:CRYPTO API) Subject: [PATCH v2 4/5] x86/cpuid: remove 'warn' parameter from filter_cpuid_features Date: Mon, 18 Jul 2022 17:11:22 +0300 Message-Id: <20220718141123.136106-5-mlevitsk@redhat.com> In-Reply-To: <20220718141123.136106-1-mlevitsk@redhat.com> References: <20220718141123.136106-1-mlevitsk@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org This parameter suppresses the warning if issue is found when this function called from early boot cpu identification code, which doesn't seem to be useful, except that it actually completely hides the warning, because next time this code is called for each CPU and when the warning is printed, the issue is already fixed, and so no warning is printed at all. Tested by using a broken CPUID with missing leaf and observing no warning printed, and with the patch a warning is printed once. Signed-off-by: Maxim Levitsky --- arch/x86/include/asm/cpufeature.h | 2 +- arch/x86/kernel/cpu/common.c | 4 ++-- arch/x86/kernel/cpu/cpuid-deps.c | 4 +--- 3 files changed, 4 insertions(+), 6 deletions(-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index 3eb5fe0d654e63..86d7fbb3f2b592 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -147,7 +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); +extern void filter_cpuid_features(struct cpuinfo_x86 *c); #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 beaea42c1b47e1..1a2f4e83e2f312 100644 --- a/arch/x86/kernel/cpu/common.c +++ b/arch/x86/kernel/cpu/common.c @@ -1485,7 +1485,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); if (this_cpu->c_bsp_init) this_cpu->c_bsp_init(c); @@ -1773,7 +1773,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); /* 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 306f285844aedc..e1b5f5c02c0106 100644 --- a/arch/x86/kernel/cpu/cpuid-deps.c +++ b/arch/x86/kernel/cpu/cpuid-deps.c @@ -150,7 +150,7 @@ cpuid_dependent_features[] = { { 0, 0 } }; -void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn) +void filter_cpuid_features(struct cpuinfo_x86 *c) { const struct cpuid_dependent_feature *df; @@ -171,8 +171,6 @@ void filter_cpuid_features(struct cpuinfo_x86 *c, bool warn) 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 Mon Jul 18 14:11:23 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maxim Levitsky X-Patchwork-Id: 592206 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 C36EBCCA47F for ; Mon, 18 Jul 2022 14:12:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233689AbiGROMQ (ORCPT ); Mon, 18 Jul 2022 10:12:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37382 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234973AbiGROMP (ORCPT ); Mon, 18 Jul 2022 10:12:15 -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 5C2E9275D4 for ; Mon, 18 Jul 2022 07:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1658153526; 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=nBIZ5inYKW+z3A/0WRI0HsZbXbpbCq0J/0LeFUWRE6c=; b=LYKIHN+ChAdJYw75wiiDRCGB6GspYUUogSuovagyADh6sR8QehBDdI2PAbRcgCX1JchQaN DGWHLcWipCzWnnq/c+I2870QzMpp2QNwrqA97sbmu2L9PdnpFXZQZvFwtkUYso5IDZEwMt Gm4c0b0N401zsv/8wehLzGsddJSzHVs= 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-512-pGEqucTQNjKNyVCGKumkbA-1; Mon, 18 Jul 2022 10:11:57 -0400 X-MC-Unique: pGEqucTQNjKNyVCGKumkbA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8C6001019C8D; Mon, 18 Jul 2022 14:11:56 +0000 (UTC) Received: from amdlaptop.tlv.redhat.com (dhcp-4-238.tlv.redhat.com [10.35.4.238]) by smtp.corp.redhat.com (Postfix) with ESMTP id 07E2C2026D64; Mon, 18 Jul 2022 14:11:50 +0000 (UTC) From: Maxim Levitsky To: linux-kernel@vger.kernel.org, kvm@vger.kernel.org Cc: Pawan Gupta , Ingo Molnar , Josh Poimboeuf , Namhyung Kim , Tony Luck , Paolo Bonzini , "H. Peter Anvin" , Arnaldo Carvalho de Melo , Thomas Gleixner , Alexander Shishkin , Tim Chen , Borislav Petkov , "David S. Miller" , Dave Hansen , "Chang S. Bae" , Jane Malalane , Kees Cook , Kan Liang , Peter Zijlstra , Maxim Levitsky , x86@kernel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)), Herbert Xu , Jiri Olsa , Mark Rutland , linux-perf-users@vger.kernel.org, linux-crypto@vger.kernel.org (open list:CRYPTO API) Subject: [PATCH v2 5/5] x86/cpuid: check for dependencies violations in CPUID and attempt to fix them Date: Mon, 18 Jul 2022 17:11:23 +0300 Message-Id: <20220718141123.136106-6-mlevitsk@redhat.com> In-Reply-To: <20220718141123.136106-1-mlevitsk@redhat.com> References: <20220718141123.136106-1-mlevitsk@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 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. For example, when one attempts to disable AVX2 but not AVX in the guest's CPUID, the guest kernel crashes in aes-ni driver, when it is used. While the aes-ni driver can also be fixed to be more eager to detect this kind of situation, it is simpler to fix this in a generic way since the kernel has all the required info in the form of a dependency table. Signed-off-by: Maxim Levitsky --- arch/x86/kernel/cpu/cpuid-deps.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/arch/x86/kernel/cpu/cpuid-deps.c b/arch/x86/kernel/cpu/cpuid-deps.c index e1b5f5c02c0106..376296c1f55ab2 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) @@ -136,6 +141,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; @@ -153,6 +162,7 @@ cpuid_dependent_features[] = { void filter_cpuid_features(struct cpuinfo_x86 *c) { const struct cpuid_dependent_feature *df; + const struct cpuid_dep *d; for (df = cpuid_dependent_features; df->feature; df++) { @@ -175,4 +185,16 @@ void filter_cpuid_features(struct cpuinfo_x86 *c) 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_cpu_cap(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)); + } }