linux-kernel - Re: [PATCH v12 09/11] x86/tsc: prepare for early sched

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:   Fri, 29 Jun 2018 17:30:25 +0300
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        Pavel Tatashin <pasha.tatashin@...cle.com>
Cc:     Steven Sistare <steven.sistare@...cle.com>,
        Daniel Jordan <daniel.m.jordan@...cle.com>,
        linux@...linux.org.uk, Martin Schwidefsky <schwidefsky@...ibm.com>,
        Heiko Carstens <heiko.carstens@...ibm.com>,
        John Stultz <john.stultz@...aro.org>, sboyd@...eaurora.org,
        x86@...nel.org, LKML <linux-kernel@...r.kernel.org>,
        mingo@...hat.com, "H. Peter Anvin" <hpa@...or.com>,
        douly.fnst@...fujitsu.com, Peter Zijlstra <peterz@...radead.org>,
        Prarit Bhargava <prarit@...hat.com>, feng.tang@...el.com,
        Petr Mladek <pmladek@...e.com>, gnomes@...rguk.ukuu.org.uk,
        linux-s390@...r.kernel.org,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: [PATCH v12 09/11] x86/tsc: prepare for early sched_clock

On Thu, 2018-06-28 at 12:43 +0200, Thomas Gleixner wrote:
> On Thu, 28 Jun 2018, Thomas Gleixner wrote:
> > I still want to document the unholy mess of what is initialized and
> > available when. We have 5 hypervisors and 3 different points in
> > early boot
> > where the calibrate_* callbacks are overwritten. The XEN PV one is
> > actually
> > post tsc_init_early() for whatever reason.
> > 
> > That's all completely obscure and any attempt of moving
> > tsc_early_init()
> > earlier than where it is now is just lottery.
> > 
> > The other issue is that double calibration, e.g. doing the PIT thing
> > twice
> > is just consuming boot time for no value.
> > 
> > All of that has been duct taped over time and we really don't want
> > yet
> > another thing glued to it just because we can.

Hmm... Good question about Intel MID, I would try to put my
understanding here.

> Boot sequence:
> 
>   start_kernel()
> 
> 	INTEL_MID:
> 		x86_intel_mid_early_setup()
> 	   	calibrate_tsc = intel_mid_calibrate_tsc
> 
> 	   	intel_mid_calibrate_tsc() { return 0; }

This sounds like a stub against very old calibration code since Intel
MID has no PIT, HPET, PMTIMER to calibrate from.

> 
>   setup_arch()
> 
> 	x86_init.oem.arch_setup();
> 	  INTEL_MID:
> 		intel_mid_arch_setup()
> 
> 		PENWELL:
> 		   x86_platform.calibrate_tsc = mfld_calibrate_tsc;
> 
> 		   MSR based magic. Value would be available right away.
> 		   
> 		TANGIER:
> 		   x86_platform.calibrate_tsc = tangier_calibrate_tsc;
> 	
> 		   Different MSR based magic. Value would be available
> 		   right away.		

This stuff is how we can read TSC frequency on those platforms.

The commit 7da7c1561366 ("x86, tsc: Add static (MSR) TSC calibration on
Intel Atom SoCs") introduced a common way for all those chips to get TSC
frequency, while forgetting remove old code.

Surprisingly, the same guy even amended legacy code in the commit
f3a02ecebed7 ("x86/tsc: Set TSC_KNOWN_FREQ and TSC_RELIABLE flags on
Intel Atom SoCs").



> INTEL_MID	intel_mid_calibrate_tsc()	intel_mid_calibrate_
> tsc()
> Generic		native_calibrate_cpu()		native_ca
> librate_cpu()
> 
> INTEL_MID	mfld_calibrate_tsc()		mfld_calibrate_ts
> c()
> PENWELL		native_calibrate_cpu()		native_ca
> librate_cpu()
> 
> INTEL_MID	tangier_calibrate_tsc()		tangier_calibr
> ate_tsc()
> TANGIER		native_calibrate_cpu()		native_ca
> librate_cpu()
> 


Taking above into consideration, I think we may just remove the legacy
code from mfld.c and mrfld.c and see what happen.

If you can tell me points to test, I can prepare patches to remove and
test on both Medfiled and Merrifield platforms (Penwell and Tangier SoCs
respectively).

> The INTEL MID stuff is wierd and not really obvious. AFAIR those
> systems
> don't have PIT or such, so they need to rely on the MSR/CPUID
> mechanisms to
> work, but that's just working because and not for obvious reasons.
> Andy,
> can you shed some light on that stuff?

Hope above makes sense.

-- 
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Intel Finland Oy