linux-kernel - Re: [PATCH] perf arm-spe: Fix incorrect sample timestamp in perf script

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]

Date:   Tue, 29 Jun 2021 08:53:55 +0800
From:   Yang Jihong <yangjihong1@...wei.com>
To:     Leo Yan <leo.yan@...aro.org>
CC:     <john.garry@...wei.com>, <will@...nel.org>,
        <mathieu.poirier@...aro.org>, <peterz@...radead.org>,
        <mingo@...hat.com>, <acme@...nel.org>, <mark.rutland@....com>,
        <alexander.shishkin@...ux.intel.com>, <jolsa@...hat.com>,
        <namhyung@...nel.org>, <james.clark@....com>,
        <andre.przywara@....com>, <linux-arm-kernel@...ts.infradead.org>,
        <linux-perf-users@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] perf arm-spe: Fix incorrect sample timestamp in perf
 script

Hello Leo,

On 2021/6/28 15:29, Leo Yan wrote:
> On Mon, Jun 28, 2021 at 02:30:56PM +0800, Yang Jihong wrote:
>> Hello Leo,
>>
>> On 2021/6/28 12:07, Leo Yan wrote:
>>> On Mon, Jun 28, 2021 at 11:45:07AM +0800, Yang Jihong wrote:
>>>
>>> [...]
>>>
>>>> The timestamp does not match. Each timestamp has a difference of
>>>> 213.98296702 seconds. Is the command I executed wrong?
>>>
>>> I don't understand what's your meaning "a difference of 213.98296702
>>> seconds".
>>>
>>> But let me give an explaination with your below examples.  You could
>>> the command "perf script" outputs the timestamp 314938.859071370 which
>>> is the kernel's timestamp, if using the command "perf script -D", it
>>> outputs the value 31515284203839 which is the Arch timer's raw counter
>>> value.
>>>
>>> In theory, the arch timer's counter is enabled at the very early
>>> time before kernel's booting (e.g. bootloaders, UEFI, etc...).  So for
>>> the kernel's timestamp, it should calibrate the timestamp and reduce
>>> the offset prior to the kernel's booting.  I think this is the reason
>>> why you observed 213.98296702 seconds difference (if compared with
>>> your own patch?)
>>>
>>> If still see any issue, please let me know.  Thanks a lot for the
>>> testing!
>>>
>> Thanks for the very detailed explanation.
>> To keep the correct relative time sequence between events in SPE and other
>> events, we should use kernel timestamp instead of arch time. Therefore, we
>> need to calibrate the time. Is this correct?
> 
> Yes, correct!
I see. Thank you for your answer.:)

Jihong
> .
>