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: <alpine.DEB.2.11.1507172351010.18576@nanos>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ