Re: KVM: x86: workaround SuSE's 2.6.16 pvclock vs masterclock issue

[Marcelo Tosatti <mtosatti@redhat.com>]

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.