linux-kernel - Re: [PATCH 3/3] x86, perf: Add PEBS frontend profiling for Skylake

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:	Sat, 18 Jul 2015 00:16:26 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andi Kleen <ak@...ux.intel.com>
cc:	Stephane Eranian <eranian@...gle.com>,
	Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] x86, perf: Add PEBS frontend profiling for Skylake

On Fri, 17 Jul 2015, Andi Kleen wrote:
> On Fri, Jul 17, 2015 at 10:11:28PM +0200, Thomas Gleixner wrote:
> > On Fri, 17 Jul 2015, Andi Kleen wrote:
> > 
> > > > I believe this mask of 0x3fff17 is wrong and should instead be
> > > > 0x7fffff based on the description of the FRONTEND
> > > > MSR I see in the SDM Table 18-54 (bit 0-22 are valid). Otherwise, some
> > > > valid latency values may be rejected.
> > > 
> > > No, my mask is correct.
> > 
> > Provide a proper argument for that. Just claiming 'my mask is correct'
> > definitely falls not into that category.
> 
> Because I actually tested the code unlike you or Stephane.

You know fcking well that I cannot test on skylake and probably
Stephane can't either.
 
> # wrmsr 0x3f7 0x3fff17
> # wrmsr 0x3f7 0x7fffff
> wrmsr: CPU 0 cannot set MSR 0x000003f7 to 0x00000000007fffff
> # 

So you think that's an explanation? No, it is NOT. It's merily an
observation on some particular piece of HW to which you have access
to exclusively.

Nobody asks you to reveal NDA information, but you should at least
have the courtesy to provide an explanation which is understandable to
others. The minimal explanation you could have provided would have been:

  "On my test machine the valid mask is 0x3fff17 contrary to the SDM
   which defines the valid mask as 0x7fffff"

'My mask is correct' is definitely not an explanation at all.

Thanks,

	tglx

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