linux-kernel - Re: [v2 0/9] Early boot time stamps for x86

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: <c0f7e0af-8fea-8a2c-d7b6-1313ca96076b@oracle.com>
Date:   Sat, 25 Mar 2017 15:45:47 -0400
From:   Pasha Tatashin <pasha.tatashin@...cle.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     x86@...nel.org, LKML <linux-kernel@...r.kernel.org>,
        mingo@...hat.com, Peter Zijlstra <peterz@...radead.org>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [v2 0/9] Early boot time stamps for x86

Hi Thomas,

Thank you very much for a very insightful feedback. I will address your 
comments, and if I have any questions, I will ask them before sending 
out the next patchset.

A few replies below:

> First of all, this "solution" is only valid for a very restricted set of
> systems and breaks others in very subtle ways.
>
> FYI, the architecture name is x86, which handles 32bit/64bit, various
> vendors and hypervisors. It's not 'arch/mymachine'.

The reason why I only targeted newer processors and 64-bit platforms was 
because these are the machines that keep growing in size: more memory, 
cpu count etc. Which, means these are the machine where we can get 
scalability problem in the future.

>
> So this needs to be integrated into the existing TSC/CPU calibration
> mechanism which works across all supported systems. And that means, that
> early TSC calibration can't be done before x86_init.oem.arch_setup() and
> hypervisor_init_platform() have been invoked.
>
> By that time, which is still pretty early in the boot process:
>
>       - boot_cpu_data has been preinitialized
>
>       - calibration functions setup has been done

This sounds good. I will sanity check that we do not spend excessive 
amount of time before x86_init.oem.arch_setup() is done on some larger 
machines, and will start early clock sometime after this call is finished.

> Putting the early TSC initialization after hypervisor_init_platform() makes
> this available for _ALL_ systems/platforms as infrastructure and allows the
> platforms to add the required bits of support via a new set of function
> pointers in struct x86_platform_ops, which btw. is a proper form of
> abstraction.

Ok

> The time between x86_64_start_kernel() and that point is in the low single
> digit millisecond range or less than a millisecond and therefor completely
> irrelevant. The first timestamps before that point will be 0 as they used
> to be.
>
> You can argue in circles about that, it's simply not debatable.

Sure, I tried perfection by having timestamps available with the first 
log message, but your proposed practicality makes sense.

> But that's only the sched clock part of the problem. If this early
> sched_clock() is available, then this needs to be fed into the setup of
> timekeeping as well, otherwise dmesg tells 50 seconds into boot and clock
> monotonic/boottime say 5, which would be confusing at best. That has not be
> solved in the first step, but definitely before something like this is
> going to be merged.

Thank you for catching this, I will make sure boottime/dmesg times match.

Thank you,
Pasha