2016-02-24 12:24-0800, Andy Lutomirski: > On Wed, Feb 24, 2016 at 12:17 PM, Radim Krčmář <rkrcmar@xxxxxxxxxx> wrote: >> 2016-02-24 09:35-0800, Peter Hornyack: >>> On Tue, Feb 23, 2016 at 7:57 PM, Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: >>>> On Tue, Feb 23, 2016 at 06:31:59PM -0800, Owen Hofmann wrote: >>>>> Regardless of my opinion, I think that a clear statement of the design >>>>> goals for kvm-clock (and kvm's implementation of the reference TSC >>>>> page) would be valuable. >>>> >>>> Documentation/virtual/kvm/timekeeping.txt >>>> >>> >>> Hi Marcelo, >>> >>> While I appreciate all of the detail in timekeeping.txt, it is not a >>> very good reference for what kvm-clock is or how it works. kvm-clock >>> is only mentioned three times in different places throughout that >>> document, and nowhere is there a very clear statement of what >>> kvm-clock is supposed to do or how it does it. >>> >>> For somebody that does not already have a deep understanding of the >>> core masterclock code, trying to understand how kvm-clock works is a >>> real challenge. >> >> I agree. Having an overview would be very helpful. >> >> Do you find anything incorrect with >> * kvmclock measures the flow of time. >> * time in kvmclock flows at the same rate as host's CLOCK_BOOTTIME. >> ? > > If we could supply CLOCK_REALTIME as well and advertise that fact to > guest userspace (perhaps with a sysctl or similar in the guest to turn > it on), it would be *awesome*. Guests with access to this feature > could simply not run ntpd/chronyd. I think that pvclock_wall_clock interface is there to do that. (If pvclock_vcpu_time_info can provide what is claimed above.) If pvclock_wall_clock version field matches with pvclock_vcpu_time_info, then the guest can add those two and get CLOCK_REALTIME. (Based on observations of angry users, the implementation lacking.) >> Maybe it would be better to say "best estimate of real time" instead of >> "CLOCK_BOOTTIME", so people wouldn't jump to conclusion that >> CLOCK_BOOTTIME has something to do with kvmclock ... > > We still need to define what zero means, if anything. I think it's better if only the difference between two reads has a meaning (the number of nanoseconds that passed). Zero is then an arbitrary value. (If we're talking about system_time.) >> Then we could mention migration (why the time becomes imprecise) and >> finish by explaining the TSC mechanism (that avoids a vmexit on every >> read) and advantages of masterclock. > > We should also explain what masterclock is, aside from being an > implementation detail. I've read the code and I still don't know. Yeah, rewriting the code would be a good deed. -- 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
