linux-kernel - Re: [PATCH 03/12] perf/x86/intel: Add perf core PMU support for Sapphire Rapids

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 26 Jan 2021 15:49:44 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     kan.liang@...ux.intel.com
Cc:     acme@...nel.org, mingo@...nel.org, linux-kernel@...r.kernel.org,
        eranian@...gle.com, namhyung@...nel.org, jolsa@...hat.com,
        ak@...ux.intel.com, yao.jin@...ux.intel.com
Subject: Re: [PATCH 03/12] perf/x86/intel: Add perf core PMU support for
 Sapphire Rapids

On Tue, Jan 19, 2021 at 12:38:22PM -0800, kan.liang@...ux.intel.com wrote:

>  Add pebs_no_block to
>   explicitly indicate the previous platforms which don't support the new
>   block fields. Accessing the new block fields are ignored on those
>   platforms.

> @@ -5475,6 +5749,7 @@ __init int intel_pmu_init(void)
>  		x86_pmu.extra_regs = intel_icl_extra_regs;
>  		x86_pmu.pebs_aliases = NULL;
>  		x86_pmu.pebs_prec_dist = true;
> +		x86_pmu.pebs_no_block = true;
>  		x86_pmu.flags |= PMU_FL_HAS_RSP_1;
>  		x86_pmu.flags |= PMU_FL_NO_HT_SHARING;
>  

> @@ -198,6 +206,63 @@ static u64 load_latency_data(u64 status)
>  	if (dse.ld_locked)
>  		val |= P(LOCK, LOCKED);
>  
> +	/*
> +	 * Ice Lake and earlier models do not support block infos.
> +	 */
> +	if (x86_pmu.pebs_no_block) {
> +		val |= P(BLK, NA);
> +		return val;
> +	}

> @@ -2026,8 +2128,10 @@ void __init intel_ds_init(void)
>  	x86_pmu.bts  = boot_cpu_has(X86_FEATURE_BTS);
>  	x86_pmu.pebs = boot_cpu_has(X86_FEATURE_PEBS);
>  	x86_pmu.pebs_buffer_size = PEBS_BUFFER_SIZE;
> -	if (x86_pmu.version <= 4)
> +	if (x86_pmu.version <= 4) {
>  		x86_pmu.pebs_no_isolation = 1;
> +		x86_pmu.pebs_no_block = 1;
> +	}
>  
>  	if (x86_pmu.pebs) {
>  		char pebs_type = x86_pmu.intel_cap.pebs_trap ?  '+' : '-';

> @@ -724,7 +729,8 @@ struct x86_pmu {
>  			pebs_broken		:1,
>  			pebs_prec_dist		:1,
>  			pebs_no_tlb		:1,
> -			pebs_no_isolation	:1;
> +			pebs_no_isolation	:1,
> +			pebs_no_block		:1;
>  	int		pebs_record_size;
>  	int		pebs_buffer_size;
>  	int		max_pebs_events;

I suppose the existing pebs_no_isolation set the bad precedent, but this
is ofcourse a bit backwards. Since we're 0 initialized, new features
should be 1, and not the other way around.