linux-kernel - Re: [RFC PATCH] perf: Provide status of known PMUs

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]

Date:	Thu, 09 Jul 2015 12:30:30 +0300
From:	Adrian Hunter <adrian.hunter@...el.com>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Ingo Molnar <mingo@...nel.org>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Vince Weaver <vincent.weaver@...ne.edu>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	linux-kernel@...r.kernel.org, Jiri Olsa <jolsa@...hat.com>,
	Stephane Eranian <eranian@...gle.com>,
	Borislav Petkov <bp@...e.de>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Andi Kleen <ak@...ux.intel.com>
Subject: Re: [RFC PATCH] perf: Provide status of known PMUs

On 09/07/15 11:50, Peter Zijlstra wrote:
> On Thu, Jul 09, 2015 at 10:48:00AM +0300, Adrian Hunter wrote:
>> Known PMUs may not be present for various reasons.
>> Provide a way for the user to know what the reason
>> is.
> 
> Not a bad idea, but I do wonder where we should draw the line on what is
> 'known'. The patch as proposed will have bts/pt listed as 'known' for
> every arch out there.
> 
> By that logic, x86 should list the ppc/sparc/mips/arm/etc.. PMUs as
> known and wrong_arch too, which might be a tad excessive.
> 
> Can we limit it to PMUs for which we've (attempted to) load the drivers?
> That would obviously make a few of your status bits redundant, but then
> you've not explained why we're interested in it.
> 
>> 	Supported
>> 	Driver error
>> 	Driver not loaded
>> 	Not supported by hardware
>> 	Wrong vendor
>> 	Unknown status
> 
> There would work.
> 
>> 	Driver not in kernel config
>> 	Not supported by kernel
>> 	Wrong architecture
> 
> These will be hard, for if we don't load the driver we don't 'know' of
> them.

Are they that hard?

The architecture one is done by perf core at the moment when the initial
status is defined e.g.

#if defined(CONFIG_X86)
#define PERF_PMU_STATUS_ARCH_X86	PERF_PMU_STATUS_UNKNOWN
#else
#define PERF_PMU_STATUS_ARCH_X86	PERF_PMU_STATUS_WRONG_ARCH
#endif

static struct known_pmu known_pmus[] = {
	KNOWN_PMU("intel_pt", "Intel", PERF_PMU_STATUS_ARCH_X86),
	KNOWN_PMU("intel_bts", "Intel", PERF_PMU_STATUS_ARCH_X86),
	KNOWN_PMU(NULL, NULL, 0),
};

For config and module the arch perf init code can check e.g.

#if !defined(CONFIG_MY_PMU) && !defined(CONFIG_MY_PMU_MODULE)
	perf_pmu_update_status("my_pmu", PERF_PMU_STATUS_NOT_CONFIG, NULL);
#elif defined(CONFIG_MY_PMU_MODULE)
	perf_pmu_update_status("my_pmu", PERF_PMU_STATUS_NOT_LOADED, NULL);
#endif


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