linux-kernel - Re: [PATCH v2] perf/x86/intel: Add support for MISPREDICT bit on Knights Landing cpus

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]

Message-ID: <CAKVxXCVoRb8Hf18AmUF7RcyNy7JACKByj2FsVOSiO31=ZHFHYQ@mail.gmail.com>
Date:   Tue, 31 Jul 2018 00:34:02 +0800
From:   Jacek Tomaka <jacekt@....com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Jacek Tomaka <jacek.tomaka@...zta.fm>
Subject: Re: [PATCH v2] perf/x86/intel: Add support for MISPREDICT bit on
 Knights Landing cpus

Ah, right:
/*
 * Due to lack of segmentation in Linux the effective address (offset)
 * is the same as the linear address, allowing us to merge the LIP and EIP
 * LBR formats.
 */

Yeah, LBR_FORMAT_EIP_FLAGS is ok as well. Would it be preffered?

On Tue, Jul 31, 2018 at 12:29 AM, Jacek Tomaka <jacekt@....com> wrote:

> I do not understand the difference between linear address vs effective
> address but LBR_FORMAT_EIP_FLAGS implies effective address, no?
>
> On Tue, Jul 31, 2018 at 12:17 AM, Peter Zijlstra <peterz@...radead.org>
> wrote:
>
>> On Mon, Jul 30, 2018 at 10:28:13PM +0800, Jacek Tomaka wrote:
>> > From: Jacek Tomaka <jacek.tomaka@...zta.fm>
>> >
>> > Problem: perf did not show branch predicted/mispredicted bit in brstack.
>> >
>> > Output of perf -F brstack for profile collected
>> >
>> > Before:
>> > 0x4fdbcd/0x4fdc03/-/-/-/0
>> > 0x45f4c1/0x4fdba0/-/-/-/0
>> > 0x45f544/0x45f4bb/-/-/-/0
>> > 0x45f555/0x45f53c/-/-/-/0
>> > 0x7f66901cc24b/0x45f555/-/-/-/0
>> > 0x7f66901cc22e/0x7f66901cc23d/-/-/-/0
>> > 0x7f66901cc1ff/0x7f66901cc20f/-/-/-/0
>> > 0x7f66901cc1e8/0x7f66901cc1fc/-/-/-/0
>> >
>> > After:
>> > 0x4fdbcd/0x4fdc03/P/-/-/0
>> > 0x45f4c1/0x4fdba0/P/-/-/0
>> > 0x45f544/0x45f4bb/P/-/-/0
>> > 0x45f555/0x45f53c/P/-/-/0
>> > 0x7f66901cc24b/0x45f555/P/-/-/0
>> > 0x7f66901cc22e/0x7f66901cc23d/P/-/-/0
>> > 0x7f66901cc1ff/0x7f66901cc20f/P/-/-/0
>> > 0x7f66901cc1e8/0x7f66901cc1fc/P/-/-/0
>> >
>> > Cause:
>> > As mentioned in Software Development Manual vol 3, 17.4.8.1,
>> > IA32_PERF_CAPABILITIES[5:0] indicates the format of the address that is
>> > stored in the LBR stack. Knights Landing reports 1 (LBR_FORMAT_LIP) as
>> > its format. Despite that, registers containing FROM address of the
>> branch,
>> > do have MISPREDICT bit but because of the format indicated in
>> > IA32_PERF_CAPABILITIES[5:0], LBR did not read MISPREDICT bit.
>> >
>> > Solution:
>> > Teach LBR about above Knights Landing quirk and make it read MISPREDICT
>> bit.
>> > ---
>> >  arch/x86/events/intel/lbr.c | 6 +++++-
>> >  1 file changed, 5 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
>> > index cf372b9055..043aa09f3a 100644
>> > --- a/arch/x86/events/intel/lbr.c
>> > +++ b/arch/x86/events/intel/lbr.c
>> > @@ -19,7 +19,7 @@ enum {
>> >       LBR_FORMAT_MAX_KNOWN    = LBR_FORMAT_TIME,
>> >  };
>> >
>> > -static const enum {
>> > +static enum {
>> >       LBR_EIP_FLAGS           = 1,
>> >       LBR_TSX                 = 2,
>> >  } lbr_desc[LBR_FORMAT_MAX_KNOWN + 1] = {
>> > @@ -1230,4 +1230,8 @@ void intel_pmu_lbr_init_knl(void)
>> >
>> >       x86_pmu.lbr_sel_mask = LBR_SEL_MASK;
>> >       x86_pmu.lbr_sel_map  = snb_lbr_sel_map;
>> > +
>> > +     /* Knights Landing does have MISPREDICT bit */
>> > +     if (x86_pmu.intel_cap.lbr_format == LBR_FORMAT_LIP)
>> > +             lbr_desc[LBR_FORMAT_LIP] |= LBR_EIP_FLAGS;
>> >  }
>>
>> So why not set lbr_format to LBR_FORMAT_EIP_FLAGS ?
>>
>
>
>
> --
> *Jacek Tomaka*
> Geophysical Software Developer
>
>
>
>
>
>
> *DownUnder GeoSolutions*
> 76 Kings Park Road
> West Perth 6005 WA, Australia
> *tel *+61 8 9287 4143 <+61%208%209287%204143>
> jacekt@....com
> *www.dug.com <http://www.dug.com>*
>



-- 
*Jacek Tomaka*
Geophysical Software Developer






*DownUnder GeoSolutions*
76 Kings Park Road
West Perth 6005 WA, Australia
*tel *+61 8 9287 4143 <+61%208%209287%204143>
jacekt@....com
*www.dug.com <http://www.dug.com>*

Content of type "text/html" skipped