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:	Fri, 26 Nov 2010 12:35:22 +0100
From:	Stephane Eranian <eranian@...gle.com>
To:	Cyrill Gorcunov <gorcunov@...nvz.org>
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 12:32 PM, Cyrill Gorcunov <gorcunov@...nvz.org> wrote:
> On Fri, Nov 26, 2010 at 2:14 PM, Cyrill Gorcunov <gorcunov@...nvz.org> wrote:
>> Stephane, this is a misprint, I'll update this comments on format
>> (giod catch btw!). in real low 32 bits are considered as cccr in ht
>> mode. wait a bit, i'll post update.
>>
>> On 11/26/10, Stephane Eranian <eranian@...gle.com> wrote:
> ...
>>>> + *    Low 32 bits
>>>> + *    -----------
>>>> + *      0-6: P4_PEBS_METRIC enum
>>>> + *     7-11:                    reserved
>>>> + *       12: Active thread
>>>
>>> I don't understand bit 12. In the actual register, it
>>> corresponds to the enable bit. Seems you're overriding
>>> its usage. Do I interpret this as saying: 0 = enable when
>>> running on thread0, 1=monitoring when running on thread1?
>>> And if I don't care?
> ...
> I believe it simply escaped quilt refresh somehow. Here is the 'refreshed'
> copy (note the low bits 12-19 updated here).
> ---
> perf, x86: P4 PMU - describe config format v2
>
> Add description of .config in a sake of RAW events.
> At least this should bring some light to those who
> will be reading this code.
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@...nvz.org>
> CC: Lin Ming <ming.m.lin@...el.com>
> CC: Stephane Eranian <eranian@...gle.com>
> CC: Peter Zijlstra <peterz@...radead.org>
> ---
>  arch/x86/include/asm/perf_event_p4.h |   63 ++++++++++++++++++++++++++++++-----
>  1 file changed, 55 insertions(+), 8 deletions(-)
>
> Index: linux-2.6.tip/arch/x86/include/asm/perf_event_p4.h
> ===================================================================
> --- linux-2.6.tip.orig/arch/x86/include/asm/perf_event_p4.h
> +++ linux-2.6.tip/arch/x86/include/asm/perf_event_p4.h
> @@ -744,14 +744,6 @@ enum P4_ESCR_EMASKS {
>  };
>
>  /*
> - * P4 PEBS specifics (Replay Event only)
> - *
> - * Format (bits):
> - *   0-6: metric from P4_PEBS_METRIC enum
> - *    7 : reserved
> - *    8 : reserved
> - * 9-11 : reserved
> - *
>  * Note we have UOP and PEBS bits reserved for now
>  * just in case if we will need them once
>  */
> @@ -788,5 +780,60 @@ enum P4_PEBS_METRIC {
>        P4_PEBS_METRIC__max
>  };
>
> +/*
> + * Notes on internal configuration of ESCR+CCCR tuples
> + *
> + * Since P4 has quite the different architecture of
> + * performance registers in compare with "architectural"
> + * once and we have on 64 bits to keep configuration
> + * of performance event, the following trick is used.
> + *
> + * 1) Since both ESCR and CCCR registers have only low
> + *    32 bits valuable, we pack them into a single 64 bit
> + *    configuration. Low 32 bits of such config correspond
> + *    to low 32 bits of CCCR register and high 32 bits
> + *    correspond to low 32 bits of ESCR register.
> + *
> + * 2) The meaning of every bit of such config field can
> + *    be found in Intel SDM but it should be noted that
> + *    we "borrow" some reserved bits for own usage and
> + *    clean them or set to a proper value when we do
> + *    a real write to hardware registers.
> + *
> + * 3) The format of bits of config is the following
> + *    and should be either 0 or set to some predefined
> + *    values:
> + *
> + *    Low 32 bits
> + *    -----------
> + *      0-6: P4_PEBS_METRIC enum
> + *     7-11:                    reserved
> + *       12:                    reserved (Enable)
> + *    13-15:                    reserved (ESCR select)
> + *    16-17: Active Thread

HW has the active thread bits reserved to 0x3.
what about you? If not, then explain what they
mean.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ