public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Liang, Kan" <kan.liang@linux.intel.com>
To: Dave Hansen <dave.hansen@intel.com>,
	Maxim Levitsky <mlevitsk@redhat.com>,
	linux-kernel@vger.kernel.org
Cc: "Chang S. Bae" <chang.seok.bae@intel.com>,
	Jiri Olsa <jolsa@kernel.org>,
	linux-perf-users@vger.kernel.org,
	Peter Zijlstra <peterz@infradead.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	"David S. Miller" <davem@davemloft.net>,
	Borislav Petkov <bp@alien8.de>, Kees Cook <keescook@chromium.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Namhyung Kim <namhyung@kernel.org>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
	<x86@kernel.org>, Jane Malalane <jane.malalane@citrix.com>,
	Tony Luck <tony.luck@intel.com>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	"open list:CRYPTO API" <linux-crypto@vger.kernel.org>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [PATCH 1/4] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap
Date: Wed, 22 Jun 2022 14:57:15 -0400	[thread overview]
Message-ID: <4a635493-4e06-af5a-d4d7-e9e669051b08@linux.intel.com> (raw)
In-Reply-To: <84c84de9-f5f1-1f8c-fa7c-6a416ea3373e@intel.com>



On 6/22/2022 10:58 AM, Dave Hansen wrote:
> On 6/22/22 07:48, 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.
>>
>> Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
> 
> Seems like a:
> 
> Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR")
> 
> would be in order.
> 
> Kan, does this change look right to you?

For the current implementation, the Arch LBR feature should be either 
supported by all the CPUs or disabled on all the CPUs. It cannot be only 
enabled for partial CPUs, even in a hybrid platform.
So the current code only check the boot CPU via static_cpu_has().

Ideally, Yes, I think it may be better to clear the bit for all CPUs, 
which makes the capability consistent among CPUs.

Thanks,
Kan
> 
>>   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);
>>   }
>>   
>>   /**
> 

  reply	other threads:[~2022-06-22 18:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-22 14:48 [PATCH 0/4] x86: cpuid: improve support for broken CPUID configurations Maxim Levitsky
2022-06-22 14:48 ` [PATCH 1/4] perf/x86/intel/lbr: use setup_clear_cpu_cap instead of clear_cpu_cap Maxim Levitsky
2022-06-22 14:58   ` Dave Hansen
2022-06-22 18:57     ` Liang, Kan [this message]
2022-06-22 19:32       ` Liang, Kan
2022-06-22 14:48 ` [PATCH 2/4] x86/cpuid: refactor setup_clear_cpu_cap/clear_feature Maxim Levitsky
2022-06-22 15:07   ` Dave Hansen
2022-06-22 15:59     ` Maxim Levitsky
2022-06-22 14:48 ` [PATCH 3/4] x86/cpuid: move filter_cpuid_features to cpuid-deps.c Maxim Levitsky
2022-06-22 15:07   ` Dave Hansen
2022-06-22 16:01     ` Maxim Levitsky
2022-06-22 14:48 ` [PATCH 4/4] x86/cpuid: check for dependencies violations in CPUID and attempt to fix them Maxim Levitsky
2022-06-22 15:32   ` Dave Hansen
2022-06-22 17:09     ` Maxim Levitsky
2022-06-22 17:18       ` Dave Hansen

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=4a635493-4e06-af5a-d4d7-e9e669051b08@linux.intel.com \
    --to=kan.liang@linux.intel.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=dave.hansen@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=keescook@chromium.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=mlevitsk@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox