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

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

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.
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?)

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.)