linux-kernel - Re: [PATCH 0/7] perf, x86: Implement AMD IBS

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: <20110812194344.GJ11702@erda.amd.com>
Date:	Fri, 12 Aug 2011 21:43:44 +0200
From:	Robert Richter <robert.richter@....com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Ingo Molnar <mingo@...e.hu>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/7] perf, x86: Implement AMD IBS

On 02.08.11 07:29:55, Peter Zijlstra wrote:
> On Mon, 2011-08-01 at 07:21 +0200, Robert Richter wrote:
> 
> > IBS is supposed to be architectural spec'ed, meaning there are no
> > family checks. IBS features are detected using cpuid.
> > 
> > So the version of the raw sampling data format could be specified with
> > the u32 capability variable. I could put the caps value to the raw
> > sample data too right after the size field. An additional advantage
> > would be that 64 bit values are memory alligned then.
> 
> Seems like a good filler :-)
> 
> > The Branch Target Address register that has been added to newer cpus
> > could simply be extended to the raw data sample, the data would still
> > be backward compatible. Userland can detect it existence from the
> > sample size or (better) from the ibs caps.
> 
> Caps would be better.

Will take caps here.

While thinking about this I realized we have to encode the pmu type
actually in the sample, because there could be one sampling file with
multiple samples from different pmus. So attr.type must be encoded and
additionaly also its mapping to the name for dynamically added pmus.
Hmm?

Somthing like this content:

 perf.data header (once): "ibs_op" -> type = 7
 perf.data sample (each): type = 7

Maybe we use the reserved field of PERF_SAMPLE_CPU for it?

> 
> > Though it is treated architectural, it isn't in the AMD64 Architecture
> > Programmer's Manual (APM). The 10h BKDG is a good source, but extended
> > IBS features are described in the family 12h bkdg (same as for 15h)
> > and the capabilities are in the cpuid spec:
> > 
> >  http://support.amd.com/us/Processor_TechDocs/41131.pdf
> >  http://support.amd.com/us/Processor_TechDocs/25481.pdf 
> 
> Right, so comparing Fam10 to Fam12,
> 
> + IbsOpCtl.19:58
> + IbsOpData.38
> - IbsOpData2.4:5

Yeah, good catch. This is due to the different northbridge
implementations. I will ask the hw guys how to handle this.

> + IbsOpData3.19

This is already in Fam10h RefC. There is also no caps bit, but should
be always clear on systems without 1G pages.

-Robert

> + IbsBrTarget
> 
> Curious that they removed a few bits, those don't seem to be enumerated
> in the IBS capability field either.
> 

-- 
Advanced Micro Devices, Inc.
Operating System Research Center

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