linux-kernel - Re: [PATCH] x86, tsc: Limit CPU frequency calibration on AMD

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: <AANLkTimYjqHJDuBg+koGETdFkJkKS7kQ-kK+fF75L0T4@mail.gmail.com>
Date:	Thu, 19 Aug 2010 11:47:35 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Borislav Petkov <bp@...64.org>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Borislav Petkov <bp@...en8.de>,
	Alok Kataria <akataria@...are.com>,
	"the arch/x86 maintainers" <x86@...nel.org>,
	Greg KH <gregkh@...e.de>, "greg@...ah.com" <greg@...ah.com>,
	"ksrinivasan@...ell.com" <ksrinivasan@...ell.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86, tsc: Limit CPU frequency calibration on AMD

On Wed, Aug 18, 2010 at 9:16 AM, Borislav Petkov <bp@...64.org> wrote:
> 6b37f5a20c0e5c334c010a587058354215433e92 introduced the CPU frequency
> calibration code for AMD CPUs whose TSCs didn't increment with the
> core's P0 frequency. From F10h, revB onward, the TSC increment rate is
> denoted by MSRC001_0015[24] and when this bit is set (which is normally
> done by the BIOS,) the TSC increments with the P0 frequency so the
> calibration is not needed and booting can be a couple of mcecs faster on
> those machines.

Very cool. This was brought up on an earlier thread and is really nice
because it also avoids the 50+ppm variability easily seen in the
calibrate results boot to boot. That variance causes difficulty
keeping close NTP sync across reboots, as the persistent drift value
is invalid after a reboot.

I recently proposed a timer based solution that doesn't block bootup,
and allows for very accurate calibration.  This might help fill the
gaps on legacy systems that do not provide TSC freq information. I'd
be interested if you had any comments.

https://kerneltrap.org/mailarchive/linux-kernel/2010/7/28/4598868

Notes on the code below.

> Signed-off-by: Borislav Petkov <borislav.petkov@....com>
> ---
>  arch/x86/kernel/tsc.c |   14 ++++++++++++--
>  1 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> index ce8e502..41b2b8b 100644
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -927,8 +927,18 @@ void __init tsc_init(void)
>        }
>
>        if (cpu_has(&boot_cpu_data, X86_FEATURE_CONSTANT_TSC) &&
> -                       (boot_cpu_data.x86_vendor == X86_VENDOR_AMD))
> -               cpu_khz = calibrate_cpu();
> +                       (boot_cpu_data.x86_vendor == X86_VENDOR_AMD)) {
> +
> +               if (boot_cpu_data.x86 > 0x10 ||
> +                   (boot_cpu_data.x86 == 0x10 &&
> +                    boot_cpu_data.x86_model >= 0x2)) {
> +                       u64 val;
> +
> +                       rdmsrl(MSR_K7_HWCR, val);
> +                       if (!(val & BIT(24)))
> +                               cpu_khz = calibrate_cpu();
> +               }
> +       }

Am I just missing the point in the code where you actually use the msr
value to assign cpu_khz? Or is the idea that the default tsc
calibration already is correct, and we don't need to further refine
it?

And yea, the calibrate_cpu function needs to be renamed.

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/