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: <871splknox.fsf@concordia.ellerman.id.au>
Date:   Thu, 13 Jul 2017 13:42:06 +1000
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Madhavan Srinivasan <maddy@...ux.vnet.ibm.com>,
        Andi Kleen <andi@...stfloor.org>,
        linuxppc-dev@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
        mikey@...ling.org
Subject: Re: [GIT PULL] Please pull JSON files for Power9 PMU events

Arnaldo Carvalho de Melo <acme@...nel.org> writes:

> Em Wed, Jul 12, 2017 at 10:09:12PM +1000, Michael Ellerman escreveu:
>> Sukadev Bhattiprolu <sukadev@...ux.vnet.ibm.com> writes:
>> > Please pull the JSON files for POWER9 PMU events.
>
>> >       perf vendor events: Add POWER9 PMU events
>> >       perf vendor events: Add POWER9 PVRs to mapfile
>  
>> I think the PVRs need work.
>  
>> You have:
>  
>> +004e0100,1,power9.json,core
>> +004e0000,1,power9.json,core
>  
>> The first is P9 DD1, but the second doesn't exist. We have it in the
>> kernel, but with a mask of 0xffff0000. From memory the perf code doesn't
>> do any masking or anything fancy, it looks for an exact match.
>  
>> So for starters you should probably drop that one and add 0x004e1200 and
>> 0x004e0200.
>
> Could this check be somehow done automatically? Using whatever is in the
> kernel sources or some IBM released document?

Not really no.

The kernel defines the major versions in arch/powerpc/include/asm/reg.h.

eg:

#define PVR_POWER8E	0x004B
#define PVR_POWER8NVL	0x004C
#define PVR_POWER8	0x004D
#define PVR_POWER9	0x004E


But that's only the top part of the value perf is looking for. To match
the full value you also need the minor revision.

I don't actually have an exhaustive list of all the Power8 revisions
that were/will ever be made. And for Power9 I definitely can't give you
a full list yet.

We do want to be able to match against the full PVR, in case we need a
different set of events for a particularly CPU revision.

But we could make it easier to maintain by making the search iterative.
ie. instead of just looking for an exact match, we could say that the
mapfile is sorted, and the first entry that matches will be used.

With a mapfile like:

004e0100,1,power9.json,core
004e,1,power9.json,core

That would match Power9 DD1 on the first line, but all other Power9 CPUs
would hit the second line. Obviously get_cpuid_str() would need to be
reworked to be match_cpuid_str() or something.

cheers

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ