linux-kernel - Re: [rfc 1/3] perf, x86: P4 PMU

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: <20101126152744.GA5620@lenovo>
Date:	Fri, 26 Nov 2010 18:27:44 +0300
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	Ingo Molnar <mingo@...e.hu>, LKML <linux-kernel@...r.kernel.org>,
	ming.m.lin@...el.com, peterz@...radead.org
Subject: Re: [rfc 1/3] perf, x86: P4 PMU - describe config format

On Fri, Nov 26, 2010 at 02:54:39PM +0100, Stephane Eranian wrote:
...
> >
> > No, single thread mode means _any_ single thread is running,
> > Stephane I'll describe some more a bit later (as only reach home),
> > ok?
> 
> From the manual:
> 
> 00 — None. Count only when neither logical processor is active.
> 01 — Single. Count only when one logical processor is active (either 0 or 1).
> 10 — Both. Count only when both logical processors are active.
> 11 — Any. Count when either logical processor is active.
> 
> In per-thread mode, you won't hit 00. I suspect you want to
> disallow 01, 10 (or CAP_SYS_ADMIN). Otherwise, you want
> to force 11, i.e., can't figure out what's going on in the other
> HT thread.
> 

 No ;) The key moment here that this flags are related to _activity_ of
logical thread and I guess they were introduced just to allow measuring
if user-space application does win from using HT or not (since for
some loads the HT simply drops the perfomance).

 But I guess what you have in mind is actually set in ESCR register --
flags T0/1_USR, T0/1_OS. And these bits are controlled by kernel and 
"measurement" of events happening on another thread is simply not
allowed, though you still can set on which CPL level measure the event
by 'exclude_kernel','exclude_user' config attributes.

 Though there are still events which are "shared" across threads,
so such events will need CAP_SYS_ADMIN permission.

 Here is what I've put in comments while were touching this code.

	/*
	 * NOTE: P4_CCCR_THREAD_ANY has not the same meaning as
	 * in Architectural Performance Monitoring, it means not
	 * on _which_ logical cpu to count but rather _when_, ie it
	 * depends on logical cpu state -- count event if one cpu active,
	 * none, both or any, so we just allow user to pass any value
	 * desired.
	 *
	 * In turn we always set Tx_OS/Tx_USR bits bound to logical
	 * cpu without their propagation to another cpu
	 */

	/*
	 * if an event is shared accross the logical threads
	 * the user needs special permissions to be able to use it
	 */
	if (p4_event_bind_map[v].shared) {
		if (perf_paranoid_cpu() && !capable(CAP_SYS_ADMIN))
			return -EACCES;
	}

  Cyrill
--
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/