linux-kernel - Re: [PATCH 06/12] perf/x86-ibs: Precise event sampling with IBS for AMD 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: <20120427125410.GG18810@erda.amd.com>
Date:	Fri, 27 Apr 2012 14:54:10 +0200
From:	Robert Richter <robert.richter@....com>
To:	Stephane Eranian <eranian@...gle.com>
CC:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 06/12] perf/x86-ibs: Precise event sampling with IBS for
 AMD CPUs

On 27.04.12 14:39:21, Stephane Eranian wrote:
> On Fri, Apr 27, 2012 at 2:34 PM, Robert Richter <robert.richter@....com> wrote:
> > On 23.04.12 11:56:59, Robert Richter wrote:
> >> On 14.04.12 12:21:46, Peter Zijlstra wrote:
> >> > On Mon, 2012-04-02 at 20:19 +0200, Robert Richter wrote:
> >> > > + * We map IBS sampling to following precise levels:
> >> > > + *
> >> > > + *  1: RIP taken from IBS sample or (if invalid) from stack
> >> > > + *  2: RIP always taken from IBS sample, samples with an invalid rip
> >> > > + *     are dropped. Thus samples of an event containing two precise
> >> > > + *     modifiers (e.g. r076:pp) only contain (precise) addresses
> >> > > + *     detected with IBS.
> >> >
> >> >             /*
> >> >              * precise_ip:
> >> >              *
> >> >              *  0 - SAMPLE_IP can have arbitrary skid
> >> >              *  1 - SAMPLE_IP must have constant skid
> >> >              *  2 - SAMPLE_IP requested to have 0 skid
> >> >              *  3 - SAMPLE_IP must have 0 skid
> >> >              *
> >> >              *  See also PERF_RECORD_MISC_EXACT_IP
> >> >              */
> >> >
> >> > your 1 doesn't have constant skid. I would suggest only supporting 2 and
> >> > letting userspace drop !PERF_RECORD_MISC_EXACT_IP records if so desired.
> >>
> >> Ah, didn't notice the PERF_RECORD_MISC_EXACT_IP flag. Will set this
> >> flag for precise events.
> >
> Why not use 2? IBS has 0 skid, unless I am mistaken.

Events with r076:p would fail then. But r076:pp is actually better and
a subset of level 1. Thus both level should work.

And there is still the question how samples with imprecise rip should
be handled. Sometimes we want to get all samples and sometimes all
samples should always contain a precise rip, other samples should be
dropped then. But there is no option or modifier for this yet.

My suggestions was to use level 1 for all samples and level 2 for
samples that only contain a precise rip, saving level 3 for future
use.

-Robert

> 
> > Peter,
> >
> > I have a patch on top that implements the support of the
> > PERF_RECORD_MISC_EXACT_IP flag. But I am not quite sure about how to
> > use the precise levels. What do you suggest?
> >
> > Thanks,
> >
> > -Robert
> >
> >>
> >> Problem is that this flag is not yet well supported, only perf-top
> >> uses it to count the total number of exact samples. Esp. perf-annotate
> >> and perf-report do not support it, and there are no modifiers to
> >> select precise-only sampling (or is this level 3?).
> >>
> >> Both might be useful: You might need only precise-rip samples (perf-
> >> annotate usage), on the other side you want samples with every
> >> clock/ops count overflow (e.g. to get a counting statistic). The
> >> p-modifier specification (see perf-list) is not sufficient to select
> >> both of it.
> >>
> >> Another question I have: Isn't precise level 2 a special case of level
> >> 1 where the skid is constant and 0? The problem I see is, if people
> >> want to measure precise rip, they simply use r076:p. Level 2 (r076:pp)
> >> is actually better than 1, but they might think not to be able to
> >> sample precise-rip if we throw an error for r076:p. Thus, I would
> >> prefer to also allow level 1.
> >>
> >> > That said, mixing the IBS pmu into the regular core pmu isn't exactly
> >> > pretty..
> >>
> >> IBS is currently the only way to do precise-rip sampling on amd cpus.
> >> IBS events fit well with its corresponding perfctr events (0x76/
> >> 0xc1). So what don't you like with this approach? I will also post IBS
> >> perf tool support where IBS can be directly used.
> >>
> >> -Robert
> >>
> >> --
> >> Advanced Micro Devices, Inc.
> >> Operating System Research Center
> >
> > --
> > Advanced Micro Devices, Inc.
> > Operating System Research Center
> >
> 

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/