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: <20140528160847.GJ29957@tassilo.jf.intel.com>
Date:	Wed, 28 May 2014 09:08:47 -0700
From:	Andi Kleen <ak@...ux.intel.com>
To:	Peter Zijlstra <peterz@...radead.org>
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 05:35:48PM +0200, Peter Zijlstra wrote:
> 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?

Let's revisit how PEBS works:

- The counter overflows and sets the GLOBAL_STATUS bit
- The PEBS assist is armed
- The counter triggers again
- The PEBS assist fires and delivers a PEBS record
- Finally it clears the GLOBAL_STATUS
- When the threshold is reached it raises an PMI

So the GLOBAL_STATUS bit is visible between the first overflow and the end 
of the PEBS record delivery.

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

That's correct. 

But it's no different than with threshold 1 and relatively rare.

-andi
-- 
ak@...ux.intel.com -- Speaking for myself only
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ