linux-kernel - Re: [PATCH 1/7] perf: introduce raw_type attribute to specify the type of a raw sample

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: <20100520154851.GS21799@erda.amd.com>
Date:	Thu, 20 May 2010 17:48:51 +0200
From:	Robert Richter <robert.richter@....com>
To:	Stephane Eranian <eranian@...gle.com>
CC:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Paul Mackerras <paulus@...ba.org>,
	David Miller <davem@...emloft.net>,
	Will Deacon <will.deacon@....com>,
	Paul Mundt <lethal@...ux-sh.org>
Subject: Re: [PATCH 1/7] perf: introduce raw_type attribute to specify the
 type of a raw sample

On 20.05.10 10:14:46, Stephane Eranian wrote:

> > We have some bits in the msrs that are reserved now, for perfctr and
> > also for ibs. We could start reusing it to mark a special sample type
> > and so on. So far, ok. Somewhen in the future there is a hw extensions
> > and these bits are not reserved anymore, what now?
> >
> You will always have the sampling period bits. Those will always be
> handled by attr->sample_period. And they correspond to the lower
> bits which are also used to encode the event select on regular counters.
> So you could identify IBS with special event selects in the lower 8 bits
> for instance.
> 
> IBS is a very model specific feature, as such the method you use to
> encode it may change.

> In my new proposal, I am not using reserved bits, I am using bits which
> are stored elsewhere in the attr structure.

Ok, maybe technically it is possible for ibs and perfctrs. You are
moving the sample count from the raw config out to sample_count
attribute, then the type is written to the new free space in the raw
config. In the kernel you do all of this in reverse order. This makes
programming events really difficult and confusing. I don't see an
advantage compared to the use of a raw_type.

> There is no guarantee your scheme will help there either. Nobody knows
> the interface to those new features. It may be that you will need more than
> 64 bits.

Right, for more than 64 bit the need another extension.

> What I am missing with raw_type is how it plays out with attr->type which
> already has RAW? Seems like you have a second level of raw.

"raw_type" is only valid together with (attr->type == PERF_TYPE_RAW).
Currently it is null (bp_type is unused and zeroed). So (raw_type ==
0) will leave everything as it is and uses the archtectures default
raw config. If we set raw_type to a value other than zero, we have a
special configuration for a special pmu feature. It looks sane to me.

> Well, I don't think you want to define an attribute for each and every
> bit of info returned by IBS. I think you need to return the IBSDATA regs
> as is and let the user pick and choose. Of course, the information can
> change, but IBS is model specific, it returns something richer than just
> a count.

I think, we all agree the ibs sample should be send back to userland
also as raw sample.

-Robert

-- 
Advanced Micro Devices, Inc.
Operating System Research Center
email: robert.richter@....com

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