linux-kernel - Re: [RFC PATCH 6/7] perf, x86: large PEBS interrupt threshold

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20140528153548.GY11096@twins.programming.kicks-ass.net>
Date:	Wed, 28 May 2014 17:35:48 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Andi Kleen <ak@...ux.intel.com>
Cc:	"Yan, Zheng" <zheng.z.yan@...el.com>, linux-kernel@...r.kernel.org,
	mingo@...e.hu, eranian@...gle.com
Subject: Re: [RFC PATCH 6/7] perf, x86: large PEBS interrupt threshold

On Wed, May 28, 2014 at 07:58:31AM -0700, Andi Kleen wrote:
> > In particular, the 0x90 offset (IA32_PERF_GLOBAL_STATUS). Intel once
> > confirmed to me that that is a direct copy of the similarly named MSR at
> > the time of the PEBS assist.
> 
> That is correct.
> 
> > 
> > This is a problem, since if multiple counters overflow multiple bits
> > will be set and its (afaict) ambiguous which event is for which counter.
> 
> When a PEBS counter overflows it clears its respective GLOBAL_STATUS bit
> automatically.

That's an ambiguous statement; did you mean to say a PEBS enabled
counter will not raise its bit in GLOBAL_STATUS on counter overflow?

Because if it does raise it, but then clears it again, its raised for a
short while and might be observed.

Anyway, you've still not entirely explained the full life cycle of those
bits in excruciating detail, please do so now.

Also, try and get it included in the SDM.

> > So until you can give an official Intel answer on how all this demuxing
> > is supposed to work and be correct this patch set isn't moving anywhere.
> 
> FWIW a patch signed off by intel.com is an official Intel statement.

Is that the reason they have such vague and non-committal Changelogs? Be
detailed and explicit.

On that same note; can someone shoot whoever writes the new SDM bits?
They're nearly impossible to comprehend, its like a patent lawyer was
involved with the end result of having a text explicitly engineered to
not be understood :-(

> > > To supply a TID it
> > > requires flushing on context switch. It can however supply the IP
> > 
> > On SNB+, previous to SNB it would need to have precise==1. I've seen no
> > such logic in. Instead you seem to artificially limit it to SNB+, for no
> > apparent reason to me.
> 
> Only tested on Sandy Bridge+

That's just ... /me lacking words.. the worst reason possible for
arbitrary limits, esp. since you guys actually have the hardware to test
older chips.

Content of type "application/pgp-signature" skipped