Re: What time is it kvm-clock?

["Radim Krčmář" <rkrcmar@redhat.com>]

2016-02-24 19:50-0800, Owen Hofmann:
> On Wed, Feb 24, 2016 at 5:19 PM, Andy Lutomirski <luto@amacapital.net> wrote:
>> Of course the guest can run its own NTP daemon or similar adjtimex
>> caller and cause the guest to stop tracking the host.  But if the host
>> passed CLOCK_MONOTONIC through, then the guest would, by default,
>> treat kvm-clock as an exactly 1GHz source and would then expose a
>> disciplined NTP-tracking CLOCK_MONOTONIC through to its user apps even
>> without an NTP client on the guest.
>>
>> If integration with the POSIX clock core were provided, the guest
>> would learn to consume the host's CLOCK_REALTIME as well, as long as
>> the host uses the tsc as its clocksource.
> 
> Your proposal, which I'd describe as a direct passthrough (to the
> extent possible) of the host gettimeofday vdso to a kvm guest, sounds
> like a much better way to get clock frequency adjustments from the
> host to the guest. But I don't know if I can think of a reason to do
> this besides "hey you don't have to run ntp". Is there a situation you
> have in mind that this helps out?

Running NTP only on the host is a good reason.
(And probably the only reason I'd call good, because any software that
 passes TSC or CLOCK_MONOTONIC timestamps between hosts needs to handle
 their differences.)

I'd prefer to avoid direct access to host's TSC or CLOCK_MONOTONIC from
the guest, so migrations aren't more complicated than they are now.
Passing host's CLOCK_REALTIME to the guest (which can be done with
pvclock) is enough for any isolated application.  (considering that
guest's pvclock ticks at expected rate, which is host's job.)

But need paravirtual interface(s) to precisely sync host and guest
CLOCK_REALTIME even on machines with VMX TSC offset and scaling, so

Is the the pvclock interface is unable to fulfill our goals?

Do you want to simplify or extend the pvclock interface?