linux-kernel - Re: [PATCH V3 13/23] perf/x86/intel/lbr: Factor out intel_pmu_store

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:   Mon, 6 Jul 2020 18:29:58 -0400
From:   "Liang, Kan" <kan.liang@...ux.intel.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     mingo@...hat.com, acme@...nel.org, tglx@...utronix.de,
        bp@...en8.de, x86@...nel.org, linux-kernel@...r.kernel.org,
        mark.rutland@....com, alexander.shishkin@...ux.intel.com,
        jolsa@...hat.com, namhyung@...nel.org, dave.hansen@...el.com,
        yu-cheng.yu@...el.com, bigeasy@...utronix.de, gorcunov@...il.com,
        hpa@...or.com, alexey.budankov@...ux.intel.com, eranian@...gle.com,
        ak@...ux.intel.com, like.xu@...ux.intel.com,
        yao.jin@...ux.intel.com, wei.w.wang@...el.com
Subject: Re: [PATCH V3 13/23] perf/x86/intel/lbr: Factor out
 intel_pmu_store_lbr



On 7/3/2020 4:59 PM, Liang, Kan wrote:
> 
> 
> On 7/3/2020 3:50 PM, Peter Zijlstra wrote:
>> On Fri, Jul 03, 2020 at 05:49:19AM -0700, kan.liang@...ux.intel.com 
>> wrote:
>>> +static void intel_pmu_store_lbr(struct cpu_hw_events *cpuc,
>>> +                struct lbr_entry *entries)
>>> +{
>>> +    struct perf_branch_entry *e;
>>> +    struct lbr_entry *lbr;
>>> +    u64 from, to, info;
>>> +    int i;
>>> +
>>> +    for (i = 0; i < x86_pmu.lbr_nr; i++) {
>>> +        lbr = entries ? &entries[i] : NULL;
>>> +        e = &cpuc->lbr_entries[i];
>>> +
>>> +        from = rdlbr_from(i, lbr);
>>> +        /*
>>> +         * Read LBR entries until invalid entry (0s) is detected.
>>> +         */
>>> +        if (!from)
>>> +            break;
>>> +
>>> +        to = rdlbr_to(i, lbr);
>>> +        info = rdlbr_info(i, lbr);
>>> +
>>> +        e->from        = from;
>>> +        e->to        = to;
>>> +        e->mispred    = !!(info & LBR_INFO_MISPRED);
>>> +        e->predicted    = !(info & LBR_INFO_MISPRED);
>>> +        e->in_tx    = !!(info & LBR_INFO_IN_TX);
>>> +        e->abort    = !!(info & LBR_INFO_ABORT);
>>> +        e->cycles    = info & LBR_INFO_CYCLES;
>>> +        e->type        = 0;
>>> +        e->reserved    = 0;
>>> +    }
>>> +
>>> +    cpuc->lbr_stack.nr = i;
>>> +}
>>
>> If I'm not mistaken, this correctly deals with LBR_FORMAT_INFO, so can't
>> we also use the intel_pmu_arch_lbr_read() function for that case?
> 

There is another more severe issue which prevents sharing the read of 
Arch LBR with LBR_FORMAT_INFO. Sorry I missed it.

For the legacy LBR, the youngest branch is stored in TOS MSR. The next 
youngest is in (TOS - 1)...

For Arch LBR and LBR PEBS, the youngest branch is always in entry 0. The 
next youngest is in entry 1...

The growth of the legacy LBR is in a reversed order of Arch LBR and LBR 
PEBS. The legacy LBR also relies on TOS. I'm afraid we cannot use the 
intel_pmu_arch_lbr_read() function for LBR_FORMAT_INFO.

I think I will only send a patch to support NO_{CYCLES,FLAGS} for all 
LBR formats.

Thanks,
Kan