linux-kernel - Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early in boot

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] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1710182256260.2477@nanos>
Date:   Wed, 18 Oct 2017 23:01:53 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Pavel Tatashin <pasha.tatashin@...cle.com>
cc:     Peter Zijlstra <peterz@...radead.org>, linux@...linux.org.uk,
        schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
        john.stultz@...aro.org, sboyd@...eaurora.org, x86@...nel.org,
        linux-kernel@...r.kernel.org, mingo@...hat.com, hpa@...or.com,
        douly.fnst@...fujitsu.com
Subject: Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early
 in boot

On Mon, 9 Oct 2017, Pavel Tatashin wrote:
> > Urgh, that's horrific.
> > 
> > Can't we simply make sched_clock() go earlier? (we're violating "notsc"
> > in any case and really should kill that option).
> > 
> > Then we can do something like so on top...
> > 
> 
> Hi Peter,
> 
> I've been thinking about your proposal, and I have one concern: sched_clock()
> can be implemented two ways either via pv_time_ops.sched_clock vectors when
> CONFIG_PARAVIRT is defined
> 
> sched_clock()
>    paravirt_sched_clock()
>       PVOP_CALL0(unsigned long long, pv_time_ops.sched_clock);
> 
> Or native via alias
> 
> sched_clock()
> 	native_sched_clock()
> 
> Using sched_clock_early() approach makes early time stamps work with both
> cases when it is determined that tsc can be used simple_udelay_calibration().
> (As we agreed I am going to change notsc to use tsc=unstable path.)
> 
> It may be not the most efficient clock for some virtualizations to use rdtsc
> directly, but since this is for early boot only, and not something that is
> going to be used after machine is booted it is OK.

The early boot time stamps are not really important for the production use
case where you care about performance.

So it's simple enough to refactor the code so it supports early time stamps
under the following conditons:

   1) TSC is stable and constant frequency

   2) TSC frequency is known early

   3) paravirt sched clock is not used

      - running on bare metal

      - forcing the paravirt stuff to not override pv_time_ops.sched_clock
        via an command line parameter

That's a valid restriction for the intended use case, i.e. timing of early
boot process.

Thanks,

	tglx