linux-kernel - RE: [PATCH] x86: Export tsc related information in sysfs

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:	Mon, 24 May 2010 11:51:56 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
Cc:	Brian Bloniarz <bmb@...enacr.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andi Kleen <andi@...stfloor.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Venkatesh Pallipadi <venki@...gle.com>, chris.mason@...cle.com,
	linux-kernel@...r.kernel.org
Subject: RE: [PATCH] x86: Export tsc related information in sysfs

On Mon, 2010-05-24 at 11:13 -0700, Dan Magenheimer wrote:
> > From: john stultz [mailto:johnstul@...ibm.com]
> > 
> > Yea, the relative instability of the tsc calibration at boot is an
> > issue for folks who want very very precise timekeeping immediately
> > after a reboot.
> > 
> > I proposed a solution to this awhile back via a boot option users
> > could use to specify the tsc_khz freq, so it would be consistent from
> > boot to boot. See: https://patchwork.kernel.org/patch/22492/
> > 
> > It didn't really go anywhere due to a lack of public interest.
> > However, if you're interested in playing with it, I can try to revive
> > the patch.
> 
> Another possibility: Optionally trust the stamped rate for the part?
> 
> I understand that on Nehalem this value is available in
> MSR_PLATFORM_INFO[15:8] (google for MSR_PLATFORM_INFO 15 8),
> but I don't know if this MSR is available on older (or AMD)
> processors.

Hmmm. That could be an option for newer cpus that I wouldn't oppose.

While Peter is correct that the stamped value is probably not very
accurate, atleast it would be constant from boot to boot, and NTP's
calculated drift value would be correct. 

We'd need a check to make sure its not way off, since NTP will give up
if its outside 500ppm.  So as long as its close to the calibrated value,
we probably could use it.

thanks
-john


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