[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7f73ec16-7262-329c-d2c3-d5481142c370@redhat.com>
Date: Wed, 27 Sep 2017 12:43:48 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Thomas Gleixner <tglx@...utronix.de>
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 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
Powered by blists - more mailing lists