2016-02-24 17:19-0800, Andy Lutomirski: > On Wed, Feb 24, 2016 at 3:35 PM, Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: >> About complaint that "its not well designed whether NTP correction >> should be applied or not". There are two different things: >> >> 1) Host clock and guest clocks synchronized. >> KVM is not responsible for that, and it can't, because >> Linux exposes a clock which is created in software >> and fixed by NTP. > > I don't understand what you mean. > > 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. kvmclock always is a 1 GHz clock, it just wasn't (maybe still isn't) a good source of source of 1 GHz. The guest can't know that it's poor unless it compares with better 1 GHz sources, for example via NTP. KVM can't know what 1 GHz is better than the host and vice-versa, so kvmclock should "accidentally" track CLOCK_BOOTTIME. But that is related to (2), I think that (1) was mainly about the offset from CLOCK_REALTIME. > 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. Using TSC in the host allows KVM to provide precise CLOCK_REALTIME, but nothing prevents us from giving host's CLOCK_REALTIME even if the host is using hpet/... as the source. >> 2) NTP frequency correction being applied to kvmclock. >> >> This only means that the frequency of the pvclock reads >> in the guest are NTP corrected. > > If the host applied NTP frequency correction to the guest, then I > would be happy. Some folks might want this to be optional. kvmclock provides time in nanoseconds, so I'd argue that NTP corrections are mandatory. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
