linux-kernel - Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being non-null is valid

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.20.1709251712180.15252@nanos>
Date:   Mon, 25 Sep 2017 17:30:40 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     mike.travis@....com
cc:     Ingo Molnar <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Bin Gao <bin.gao@...ux.intel.com>,
        Prarit Bhargava <prarit@...hat.com>,
        Dimitri Sivanich <dimitri.sivanich@....com>,
        Andrew Banman <andrew.banman@....com>,
        Russ Anderson <russ.anderson@....com>,
        linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH 1/3] x86/kernel: Add option that TSC on Socket 0 being
 non-null is valid

On Thu, 21 Sep 2017, mike.travis@....com wrote:
> +/*
> + * TSC on socket 0 being non-zero may be correct as set by BIOS
> + */
> +static int __read_mostly tsc_socket0_nonzero;
> +
>  /* native_sched_clock() is called before tsc_init(), so
>     we must start with the TSC soft disabled to prevent
>     erroneous rdtsc usage on !boot_cpu_has(X86_FEATURE_TSC) processors */
> @@ -244,6 +249,20 @@ int check_tsc_unstable(void)
>  }
>  EXPORT_SYMBOL_GPL(check_tsc_unstable);
>  
> +void mark_tsc_socket0_nonzero(char *reason)
> +{
> +	tsc_socket0_nonzero = 1;
> +	pr_info("Marking TSC non-zero value valid for socket 0 due to %s\n",
> +		reason);
> +}
> +EXPORT_SYMBOL_GPL(mark_tsc_socket0_nonzero);
>
> +int check_tsc_socket0_nonzero(void)
> +{
> +	return tsc_socket0_nonzero;
> +}
> +EXPORT_SYMBOL_GPL(check_tsc_socket0_nonzero);

Is there a real reason to export these functions? I can't see the UV early
boot code and tsc_sync being built as modules in the forseeable future, but
perhaps you know more than I do :)

Aside of that I really do not like this kind of special case hackery. The
real question is whether we need to enforce TSC_ADJUST == 0 on the boot cpu
at all. In principle we don't anymore now that we handle that TSC deadline
timer wreckage cleanly.

But the UV 'boot chassis at different times' brings me to a related
question:

How is this setup dealing with ART (Always Running Timer, which is
distributed over PCIe for hardware timestamping and hardware assisted event
correlation)?

I assume that ART on UV is also per chassis, but that means that the
documented relation ship of:

	TSC = ART * n/d + offset

where $offset is system wide (the TSC_ADJUST value of the boot cpu), is
not applicable.

Is there some other magic in play which makes ART work across chassis?

Thanks,

	tglx