All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maxim Levitsky <mlevitsk@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Ingo Molnar <mingo@redhat.com>,
	Josh Poimboeuf <jpoimboe@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Tony Luck <tony.luck@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"Chang S. Bae" <chang.seok.bae@intel.com>,
	Jane Malalane <jane.malalane@citrix.com>,
	Kees Cook <keescook@chromium.org>,
	Kan Liang <kan.liang@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, Herbert Xu <herbert@gondor.apana.org.au>,
	Jiri Olsa <jolsa@kernel.org>, Mark Rutland <mark.rutland@arm.com>,
	linux-perf-users@vger.kernel.org,
	"open list:CRYPTO API" <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
Date: Tue, 20 Sep 2022 11:20:47 +0300	[thread overview]
Message-ID: <c105971a72dfe6d46ad75fb7e71f79ba716e081c.camel@redhat.com> (raw)
In-Reply-To: <Yyh9RDbaRqUR1XSW@zn.tnic>

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 <kan.liang@linux.intel.com>
> > Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> > ---
> >  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





  reply	other threads:[~2022-09-20  8:23 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-18 14:11 [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
2022-07-18 14:11 ` [PATCH v2 1/5] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap Maxim Levitsky
2022-09-19 14:31   ` Borislav Petkov
2022-09-20  8:20     ` Maxim Levitsky [this message]
2022-09-26 13:12       ` Borislav Petkov
2022-09-28 10:49         ` Maxim Levitsky
2022-10-20  8:59           ` Borislav Petkov
2022-10-20  9:05             ` Herbert Xu
2022-10-20 10:21               ` Maxim Levitsky
2022-10-20 11:13                 ` Borislav Petkov
2022-10-22 21:08             ` H. Peter Anvin
2022-11-02 13:40             ` Paolo Bonzini
2022-11-02 14:27               ` Elliott, Robert (Servers)
2022-11-02 16:23                 ` H. Peter Anvin
2022-11-02 18:19                   ` H. Peter Anvin
2022-11-02 19:14                     ` Elliott, Robert (Servers)
2022-11-03 13:26                   ` Paolo Bonzini
2022-11-03 13:30                 ` Paolo Bonzini
2022-10-20 15:17   ` [tip: x86/urgent] perf/x86/intel/lbr: Use setup_clear_cpu_cap() instead of clear_cpu_cap() tip-bot2 for Maxim Levitsky
2022-07-18 14:11 ` [PATCH v2 2/5] x86/cpuid: refactor setup_clear_cpu_cap()/clear_cpu_cap() Maxim Levitsky
2022-10-21 16:19   ` Borislav Petkov
2022-11-07 19:10     ` Borislav Petkov
2022-11-07 21:57       ` Borislav Petkov
2022-07-18 14:11 ` [PATCH v2 3/5] x86/cpuid: move filter_cpuid_features to cpuid-deps.c Maxim Levitsky
2022-07-18 14:11 ` [PATCH v2 4/5] x86/cpuid: remove 'warn' parameter from filter_cpuid_features Maxim Levitsky
2022-07-18 14:11 ` [PATCH v2 5/5] x86/cpuid: check for dependencies violations in CPUID and attempt to fix them Maxim Levitsky
2022-07-28  7:30 ` [PATCH v2 0/5] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
2022-08-01 16:05   ` Maxim Levitsky
2022-08-01 16:31     ` Dave Hansen
2022-08-01 16:41       ` Maxim Levitsky
2022-09-19 13:43     ` Maxim Levitsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c105971a72dfe6d46ad75fb7e71f79ba716e081c.camel@redhat.com \
    --to=mlevitsk@redhat.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=jane.malalane@citrix.com \
    --cc=jolsa@kernel.org \
    --cc=jpoimboe@kernel.org \
    --cc=kan.liang@linux.intel.com \
    --cc=keescook@chromium.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=pawan.kumar.gupta@linux.intel.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.