linux-kernel - Re: [PATCH v5 1/6] timekeeper: introduce extended clocksource reading callback

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.20.1709271103420.4773@nanos>
Date:   Wed, 27 Sep 2017 11:18:37 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Paolo Bonzini <pbonzini@...hat.com>
cc:     Denis Plotnikov <dplotnikov@...tuozzo.com>, rkrcmar@...hat.com,
        kvm@...r.kernel.org, john.stultz@...aro.org, mingo@...hat.com,
        hpa@...or.com, linux-kernel@...r.kernel.org, x86@...nel.org,
        rkagan@...tuozzo.com, den@...tuozzo.com
Subject: Re: [PATCH v5 1/6] timekeeper: introduce extended clocksource reading
 callback

On Tue, 26 Sep 2017, Paolo Bonzini wrote:
> However, if get_device_system_crosststamp ran with kvmclock or Hyper-V
> clocksource, the two values stored by read_with_stamp would be
> different, basically a (TSC, nanoseconds) pair.

And that's exactly the problem. The cross time stamp infrastructure keeps
the system clocksource (e.g. TSC) and the reference clock (e.g. ART)
separate. There is enforcement that the two are coupled which I pointed out
in the other mail, but conceptually they are different things and we are
not going to change that and add voodoo callbacks which return different
timestamps from different sources into the clocksource.

So if you want to map kvmclock to the existing infrastructure then:

   device clock:  	       maps to the hypervisor clock
   system reference clock:     maps to REF_TSC
   system timekeeper clock:    maps to TSC

Even if REF_TSC and TSC are the same physically conceptually they are
different.

To make use of the existing infrastructure you have to provide means to
capture HV clock and reference clock atomically. Thats probably something
he hypervisor provides as a value pair HVCLOCK_NSEC, REF_TSC_VAL.

And then you can correlate system time to HVCLOCK_NSEC via REF_TSC_VAL
because that has a fixed ratio / offset to the system TSC.

Thanks,

	tglx