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

Marcelo Tosatti
2015-01-22T18:13:07Z

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.