From mboxrd@z Thu Jan 1 00:00:00 1970 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 8D6EEC54EE9 for ; Tue, 20 Sep 2022 08:24:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231609AbiITIYJ (ORCPT ); Tue, 20 Sep 2022 04:24:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33276 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231449AbiITIXK (ORCPT ); Tue, 20 Sep 2022 04:23:10 -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 ESMTPS id 096A467148 for ; Tue, 20 Sep 2022 01:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663662054; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1+rrVO93NDmOlIUnSwDzWkTM+P8LQ+RPw309XhLJrYc=; b=O/r6KuBJ9LSnyOrm9z4C23xyOaxAZTHfEoJ2t1ZmiLVfHW37j7YfoCeiaq8rKgNDWmzK6h PS1HKCtwGTQhYOg9LZJwZ5coqg2/0GlI65RFXP6aF70TFyNMpyHJs8oP31tYafCTDPtqoX 19c/ISN2TodTdsn3gzxkCpGZxc6Ark0= Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-388-hanWjbhPOi-n_EUsfHystA-1; Tue, 20 Sep 2022 04:20:53 -0400 X-MC-Unique: hanWjbhPOi-n_EUsfHystA-1 Received: by mail-wr1-f72.google.com with SMTP id d25-20020adf9b99000000b0022adb03aee6so839181wrc.6 for ; Tue, 20 Sep 2022 01:20:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date; bh=1+rrVO93NDmOlIUnSwDzWkTM+P8LQ+RPw309XhLJrYc=; b=fKyM2YGH1yE3GOXY6aocBpqO7kMAr+G9ZehiVqtFtE7dBVWV8PD4phHLjs9hA4ifCg MEHSy276rDx1eceaelQ6j5pfbcb9cOKEQ9Yqj+5FtzmFx95GpeLIzwnCSZLq9H/R8xTD Bu7kwZwS1jf9ircYIqt8CuY8Q28tf1n2WAuC5jIE6HF5kfzkj7rPnLBz/kY64Y04ccEs 0PI0wGIGkD37gplRQiCt/8ECbpg/yntv+yRCrfVCfvNZWQSU8jHn/JObNLOluXBirfWF 50kMK6TTwe+6Y56x0O/NZqVAmRhOrPjO3JX4okA4i7vS5SjNX7TZq0VBP8UMe/FunH56 lGTA== X-Gm-Message-State: ACrzQf1QjgZPhiuHHpo+X3MRso1kXYG2Lcuf39CNu6e/ahS0xAh+IKOF P2HAqBTayV/HatRJWRCpDgWFfHo7lYYmvscW9hrnuu6/Ivewb9BZCDxM0QC55WsSlY9iCYk444I Jy9C+4HwakZmFhxOL+w6alxIAqd+Kyw== X-Received: by 2002:adf:eb52:0:b0:223:9164:b5b4 with SMTP id u18-20020adfeb52000000b002239164b5b4mr13499012wrn.518.1663662051681; Tue, 20 Sep 2022 01:20:51 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4iQ6R42icnZ09Saqbmpo6z2thRHisAaEDC27R2xhSI+2071PE+zluAAoYhYgRGg3JTJpzmOw== X-Received: by 2002:adf:eb52:0:b0:223:9164:b5b4 with SMTP id u18-20020adfeb52000000b002239164b5b4mr13499001wrn.518.1663662051415; Tue, 20 Sep 2022 01:20:51 -0700 (PDT) Received: from [10.35.4.238] (bzq-82-81-161-50.red.bezeqint.net. [82.81.161.50]) by smtp.gmail.com with ESMTPSA id iw18-20020a05600c54d200b003b492b30822sm1436129wmb.2.2022.09.20.01.20.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Sep 2022 01:20:50 -0700 (PDT) Message-ID: Subject: Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap From: Maxim Levitsky To: Borislav Petkov Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, 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 , "David S. Miller" , Dave Hansen , "Chang S. Bae" , Jane Malalane , Kees Cook , Kan Liang , Peter Zijlstra , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , Herbert Xu , Jiri Olsa , Mark Rutland , linux-perf-users@vger.kernel.org, "open list:CRYPTO API" Date: Tue, 20 Sep 2022 11:20:47 +0300 In-Reply-To: References: <20220718141123.136106-1-mlevitsk@redhat.com> <20220718141123.136106-2-mlevitsk@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 (3.40.4-5.fc34) MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-perf-users@vger.kernel.org On Mon, 2022-09-19 at 16:31 +0200, Borislav Petkov wrote: > On Mon, Jul 18, 2022 at 05:11:19PM +0300, Maxim Levitsky wrote: > > 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); > > setup_clear_cpu_cap() has a very specific purpose - see > apply_forced_caps(). > > This whole call sequence is an early_initcall() which is way after the > whole CPU features picking apart happens. > > So what is actually this fixing? > If I understand that correctly, the difference between clear_cpu_cap and setup_clear_cpu_cap is that setup_clear_cpu_cap should be called early when only the boot cpu is running and it 1. works on 'boot_cpu_data' which represents the boot cpu. 2. sets a bit in 'cpu_caps_cleared' which are later applied to all CPUs, including these that are hotplugged. On the other hand the clear_cpu_cap just affects the given 'struct cpuinfo_x86'. Call of 'clear_cpu_cap(&boot_cpu_data, X86_FEATURE_ARCH_LBR)' is weird since it still affects 'boot_cpu_data' but doesn't affect 'cpu_caps_cleared' I assumed that this was a mistake and the intention was to disable the feature on all CPUs. I need this patch because in the next patch, I change the clear_cpu_cap such as it detects being called on boot_cpu_data and in this case also clears bits in 'cpu_caps_cleared', thus while this patch does introduce a functional change, the next patch doesn't since this is the only place where clear_cpu_cap is called explicitly on 'boot_cpu_data' I do now notice that initcalls are run after smp is initialized, which means that this code doesn't really disable the CPUID feature on all CPUs at all. Maybe we can drop the call instead, which does seem to be wrong? Best regards, Maxim Levitsky