linux-kernel - Re: [PATCH 0/3] Improve TSC as a clocksource under VMware

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:	Tue, 21 Oct 2008 11:04:54 -0700
From:	Alok Kataria <akataria@...are.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	LKML <linux-kernel@...r.kernel.org>,
	the arch/x86 maintainers <x86@...nel.org>,
	Daniel Hecht <dhecht@...are.com>
Subject: Re: [PATCH 0/3] Improve TSC as a clocksource under VMware

On Tue, 2008-10-21 at 10:40 -0700, Andi Kleen wrote:
> > > It would be far nicer if VMware just emulated the "constant_tsc" bit
> > > in the AMD CPUID leaf, instead of adding all that gunk to Linux.
> > > Right now it's only checked for AMD CPUs, but that could be changed.
> >
> > I am not sure if we might want to skip the tsc_sync code for all the
> > cpus which have this constant_tsc bit set, can we ?
> 
> It should be ok, although normally sanity checks should be kept.
> 
> > Since i have seen that we can have cases where tsc is marked unstable as
> > its not found to be perfectly stable between cpus, we have to make sure
> > that we avoid this check when on VMware. Even with slight difference in
> 
> Normally tsc sync should only fail when the error is large.
> It cannot detect very small derivation by design. It's more like
> a sanity check "does the TSC sync look half way sane"

FWIU from the code, even if  cpu A's TSC is just 1 tick behind that of
cpu B, we increment the nr_wraps value.
And the code expects that there are no wraps in TSC throughout the
20msec measurement window. 
So IMO its fairly easy to fail this test.
> 
> If it fails on VMware perhaps the margins are not big enough or
> something else is fishy.
> 
> But still it could be skipped with constant_tsc. But again you
> shouldn't really fail that check -- if you do fail are you
> sure your clock is really synchronized enough that there
> are no observable differences?
> 
> > TSC between cpus, we know that TSC is the best available clocksource as
> > the hypervisor (VMware) makes sure that the drift is always marginal (if
> > ever there is).
> 
> The drift has to be unobservable, otherwise you still risk
> non monotonity.  Also when there is drift it has to be short
> term only, otherwise it would accumulate over longer times.

Usually the problem is more pronounced during the boot process, the
TSC's between processors are not perfectly in sync at bootup but the
drift is not observable later, and from timekeeping perspective we are
perfectly fine.

Thanks,
Alok


> 
> -Andi
> 
> --
> ak@...ux.intel.com

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