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  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:	Thu, 19 Jun 2014 22:31:29 +0200
From:	Stephane Eranian <eranian@...gle.com>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	"mingo@...e.hu" <mingo@...e.hu>, Joe Mario <jmario@...hat.com>,
	Don Zickus <dzickus@...hat.com>, Jiri Olsa <jolsa@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH 1/2] perf/x86: update Haswell PEBS event constraints

On Thu, Jun 19, 2014 at 10:18 PM, Andi Kleen <ak@...ux.intel.com> wrote:
>> I don't quite understand that.
>> You need to know which events support PEBS. You need a table
>
> We're talking about the kernel allowing things here.
> Yes the user still needs to know what supports PEBS, but
> that doesn't concern the kernel.
>
Just need to make sure you don't return bogus information.

> You can just allow it for all, it's a nop if the event doesn't
> support it. And also the fields like DataLA are simply 0 when
> not supported.
>

Let's take a example. If I do resource_stalls:pp, the kernel
will let it go through and clear the PMI bit on the config as
is required for PEBS mode. The counter will count normally
and never fire an interrupt, even when it overflows. It would
never execute the PMI handler and thus never look at the
PEBS content. You'd never get any samples.

> The only thing you need is a rule to limit to 4 counters.
>
> Then only cases that are special (PREC_DIST, extra registers)
> would need to be handled explicitely.
>
extra registers do no impose counter constraints. That's the approach
used by Intel tools to simplify scheduling. As I said in my patch, in
Linux we do this differently.

So yes, you'd need this for PREC_DIST and precise store on SNB, IVB.
--
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/

Powered by blists - more mailing lists