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  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]
Date:   Mon, 16 Jan 2017 17:47:18 -0200
From:   Marcelo Tosatti <mtosatti@...hat.com>
To:     Radim Krcmar <rkrcmar@...hat.com>,
        Miroslav Lichvar <mlichvar@...hat.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>,
        Richard Cochran <richardcochran@...il.com>
Subject: Re: [patch 3/3] PTP: add kvm PTP driver

On Mon, Jan 16, 2017 at 05:36:55PM -0200, Marcelo Tosatti wrote:
> On Mon, Jan 16, 2017 at 07:01:48PM +0100, Radim Krcmar wrote:
> > > Sorry the clock difference is 10ns now. So the guest clock is off by _10 ns_ 
> > > of the host clock.
> > 
> > That is pretty good.
> 
> Yes.
> 
> > > You are suggesting to use getcrosststamp instead, to drop the (rdtsc() -
> > > guest_tsc) part ?
> > 
> > Yes, it results in simpler code, doesn't create dependency on the
> > dreaded kvmclock, and is the best we can currently do wrt. precision.

Even if the PHC sync algorithm manages to detect that the clock read is
incorrect, consider the following:

Variability in the VM-entry code path, such as cache effects and interrupts would cause
certain readings to be longer then the average (assuming an average
where cache is hot).

Using the TSC removes this variability, which can be large in case of
non realtime guests, where you do:

	1. kvm_hypercall.
	2. read host realtime clock.
	3. schedule out qemu-kvm vcpu.
	4. schedule in qemu-kvm vcpu.

So using the delta between read host realtime and 
->gettime64 increases precision and decreases variability.

> Sorry, unless i am misunderstanding how this works, it'll get the guest clock
> 2us behind, which is something not wanted.
> 
> Miroslav, if ->gettime64 returns the host realtime at 2us in the past, 
> this means Chrony will sync the guest clock to
> 
> host realtime - 2us
> 
> Is that correct?
> 

Powered by blists - more mailing lists