DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 56EA77CDE1
Subject: Re: [PATCH v5 1/6] timekeeper: introduce extended clocksource reading
 callback
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Denis Plotnikov <dplotnikov@virtuozzo.com>, rkrcmar@redhat.com,
        kvm@vger.kernel.org, john.stultz@linaro.org, mingo@redhat.com,
        hpa@zytor.com, linux-kernel@vger.kernel.org, x86@kernel.org,
        rkagan@virtuozzo.com, den@virtuozzo.com
References: <1504106628-172372-1-git-send-email-dplotnikov@virtuozzo.com>
 <1504106628-172372-2-git-send-email-dplotnikov@virtuozzo.com>
 <alpine.DEB.2.20.1709252322120.2418@nanos>
 <7b886c9f-70a7-951b-ff6f-f77f263754e7@redhat.com>
 <alpine.DEB.2.20.1709270946200.1945@nanos>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <7f73ec16-7262-329c-d2c3-d5481142c370@redhat.com>
Date: Wed, 27 Sep 2017 12:43:48 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1709270946200.1945@nanos>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2558
Lines: 74

On 27/09/2017 10:52, Thomas Gleixner wrote:
> But there is no requirement that current clocksource is TSC. The
> requirement is:
> 
>   The hardware reference clock, the one which can be captured atomically
>   with device clock (PTP, audio whatever), is the coupled clock of the
>   current timekeeping clocksource. Both have a fixed ratio and offset.
> 
> That's completely independend of TSC. TSC/ART are a particular hardware
> implementation which can use that infrastructure because they fulfil the
> requirement.

Ok, this helps.

> So please stop these uninformed claims about brokeness and TSC
> requirements.

It was a question, not an uninformed claim.  You answered the question now.

> Instead please sit down and figure out whether your
> particular use case of kvmclock/hyperv clock actually fit into that
> functionality, i.e. whether you have
> 
>     1) 'device time'
>     2) 'system reference time'
>     3) 'system time'
> 
> where
> 
>     #1 and #2 can be captured atomically
> 
>     #2 and #3 are coupled clocks with a fixed ratio and offset
> 
> If those requirements are fulfilled then you can simply use it as is and it
> will give you CLOCK_MONOTONIC and CLOCK_REALTIME for the captured device
> time.
> 
> If your use case is different and does not fit into that picture then
> please write it up clearly what you are trying to achieve and we can
> discuss how to make it work w/o adding duct tape hackery.

Yes, I understand better now why you consider read_with_stamp a hack.
And it is---but I was confused and couldn't think of anything better.

The definitions do fit KVM, and indeed there is ptp-kvm that does
something very similar to what you describe in the other mail.  We have:

	#1 is host time
	#2 is host TSC
	#3 is guest TSC

We know that #2 and #3 have a fixed ratio and offset.  The point is
whether #1 and #2 can be captured atomically.

For PTP-KVM, the host tells the guest; if capturing the two is
impossible, it fails the hypercall and ioctl(PTP_SYS_OFFSET_PRECISE)
fails too.

Right now, the hypercall fails if the host clocksource is not the TSC
clocksource, which is safe.

These patches are about ascertaining whether #1 and #2 can be captured
atomically in a more generic way.  In the read_with_stamp case:

- if it returns true, it gives an atomic reading of #1 and #2

- if it returns false, it gives a reading of #1 only.


I think the hook should be specific to x86.  For example it could be an
array of function pointers, indexed by vclock_mode, with the same
semantics as read_with_stamp.

Paolo