Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp3390230imw; Mon, 18 Jul 2022 07:18:09 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vOfpJ/05yKlTqCUwL9Jekg47fkwTCOZ7VvqKzh91cJNnyM0PWWNDt+t1Pyq+JsV94vNhWo X-Received: by 2002:a17:906:58d1:b0:72e:e049:cf00 with SMTP id e17-20020a17090658d100b0072ee049cf00mr19162968ejs.361.1658153889481; Mon, 18 Jul 2022 07:18:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658153889; cv=none; d=google.com; s=arc-20160816; b=agPFqBj9TisU4XGOrO5grITQmV3L+2qulBaCEWaeUSbowkfCqUp1HHBZ3Sj0f6vyHo eakVmR57ItAbTnTnWJNP9VU/hT81HyMippQ4GWPLAcJASHrqm7mcHzjAf/zWyLGRn5cF AA2oLpRzqDu8r4q9p2x1Aei9wbffGR8oOm0TbBU5+Bz8gnILy7jktBQEs6IzmET687L9 YAc10mMHMoyTZFwaAFR1Fswx4S0a7tD+Acsus8K9y4FXFdK5cc2jDFLgRLXd0GQPEeMN M3WbyFigqMiak5N/Vm3KWSqqQzDhltPYARWPe0uIXGa7b+nhChVSX9ZlSEaAdPcRNeXs nAGA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=w5ar1xL/lWu4+LzORYC79cebbS3mhMxSowTJXzIDy14=; b=bxxmx37vDLCMNgmtGMSf4UPCw5oOwnqXVe7VKpKfaaCPq6CW2aAY+EjNpNLh1MYx7v BCbMu1J4vzrmwRDQj/4SU8PZEvCilfVdRTRR95/n6Kq4LIAbi6kVxXx0vr6HEAAhGeb7 o/ZReRfDBRMXpssMTO7uYZVssP6bWUouGF53cIcDDd47rWReY8LIxsZVvYl513qDKUlM lk+4lpFFZRaKJ8TFSoJgc326tSiITt7xxzoM7QBYMuWmQlMB7BtRg8YIDH7YqasKspf/ H8SH9d6Zi5z0zL5E3aZEwhtTZTcLYCwxrPp7l5XjecvIQOAxhIj6kx9r5URVw2z2JTpA cepQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Oy0g75aH; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i5-20020a05640242c500b00437a61a5751si19300232edc.571.2022.07.18.07.17.44; Mon, 18 Jul 2022 07:18:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Oy0g75aH; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235741AbiGROLz (ORCPT + 99 others); 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 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net 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); } -- 2.34.3