linux-kernel - Re: [patch 3/3] PTP: add kvm PTP driver

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: <20170116194715.GA8017@amt.cnet>
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?
>