On Thu, Jan 22, 2015 at 02:59:28PM +0100, Radim Krčmář wrote: > 2015-01-21 23:40-0200, Marcelo Tosatti: > > On Wed, Jan 21, 2015 at 06:00:37PM +0100, Radim Krčmář wrote: > > > 1) The bug happens because a guest expects greater precision. > > > I consider that as a guest problem. kvmclock never guaranteed > > > anything, so unmet expectations should be a recoverable error. > > > > delta = pvclock_data.tsc_timestamp - RDTSC > > > > Guest expects delta to be smaller than a given threshold. It does > > not expect greater precision. > > > > Size of delta does not affect precision. > > I don't understand what the guest wants to achieve with the delta. Neither do I. It seems to assume that TSC delta is unreliable, while system_timestamp is reliable. Therefore if TSC delta is large, request a system_timestamp update, which keeps TSC delta small. > I thought that checking this only made sense if the guest didn't believe > that PV clock works with large delta. And they only want precision. > (What else is there on a clock?) Ok right they assumed TSC was not reliable? > Disclaimer: I haven't read the code. (It wasn't in vanilla 2.6.16.) > > > > 2) With time, the probability that 2.6.16 is used is getting lower, > > > while people looking at KVM's code appear. > > > - At what point are we going to drop 2.6.16 support? > > > (We shouldn't let mistakes drag us down forever ... > > > Or are we dooming KVM on purpose?) > > > > One of the features of virtualization is to be able to run old > > operating systems? > > True, I'll assign higher priority to it. > > > > 3) The patch made me ask more silly questions than it answered :) > > > (Why can't other software depend on previous behavior? > > > > Documentation/virtual/kvm/msr.txt: > > > > whose data will be filled in by the hypervisor periodically. > > Only one write, or registration, is needed for each VCPU. The interval > > between updates of this structure is arbitrary and implementation-dependent. > > The hypervisor may update this structure at any time it sees fit until > > anything with bit0 == 0 is written to it. > > Exactly, this made me think it is not a KVM problem. > (And I wondered why wouldn't we yield to other misuses of it.) > > > > > Supporting old guests is important. > > > > > > It comes at a price. > > > (Mutually exclusive goals are important as well.) > > > > This phrase is awkward. Overlapping goals are negative, > > then? (think of a large number of totally overlapping goals). > > Even if both mutually exclusive goals are positive, we can only choose > one. (Sorry, I don't see the neccessity between overlapping goals and > negativity.) I get your point about "Mutually exclusive goals". Just being annoying. -- 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
