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: <20171130004806.Horde.4S2BOmF5H2xdXhkTbGmMv0_@www.imp.polymtl.ca>
Date:   Thu, 30 Nov 2017 00:48:06 +0000
From:   Abderrahmane Benbachir <abderrahmane.benbachir@...ymtl.ca>
To:     Pavel Tatashin <pasha.tatashin@...cle.com>
Cc:     Peter Zijlstra <peterz@...radead.org>, rostedt@...dmis.org,
        linux-kernel@...r.kernel.org, mingo@...hat.com,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Very Early boot time stamps support


Pavel Tatashin <pasha.tatashin@...cle.com> a écrit :

> Hi Abderrahmane,
>
>> I'm implementing a feature in ftrace to enable very early function tracing,
>> I'm using tsc when x86_tsc feature is available, but it seems that you did
>> similar work in your patch "[PATCH v9 0/6] Early boot time stamps for x86".
>>
>> I need to record timestamps at the start of start_kernel(), the first
>> function to be traced is set_task_stack_end_magic.
>
> Early boot time stamps are available only after platforms are
> initialized. This happens in:
>
> start_kernel()
>  setup_arch()
>   kvmclock_init() <-- right after this call.
>
> This was a request from Thomas, not to invent a new TSC calibration,
> and instead rely on what is already available.
This seems related to kvm/hypervisor, is there any available TSC calibration
that could be used independently from kvm ?

>
> So, while not covering the whole boot process, early boot clock is
> still initialized pretty early.
>
> Here a few ideas how to make early boot clock to initialize earlier.
>
> 2. We could initialize TSC earlier only on those CPUs where hardware
> tells us specifically TSC frequency i.e. cpuinfo(15) is available. See
> native_calibrate_tsc() for an example. This is true for all the latest
> Intel CPUs. Unfortunately, this does not work with qemu, as it returns
> some garbage in cpuinfo(15), even when processor supports this feature
> natively.
Is this a bug in Qemu ?




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ