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

Radim Krčmář
2015-01-22T13:59:32Z

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