Re: [Xen-devel] [PATCH v11] tolerate jitter in cpu_khz calculation to avoid TSC emulation

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.12.18 at 10:04, <olaf@xxxxxxxxx> wrote:
> Am Thu, 13 Dec 2018 01:45:39 -0700
> schrieb "Jan Beulich" <JBeulich@xxxxxxxx>:
> 
>> >>> On 13.12.18 at 09:18, <olaf@xxxxxxxxx> wrote:  
>> > Am Wed, 12 Dec 2018 09:39:25 -0700
>> > schrieb "Jan Beulich" <JBeulich@xxxxxxxx>:
>> >   
>> >> >>> On 12.12.18 at 16:20, <olaf@xxxxxxxxx> wrote:    
>> >> > If a domU uses TSC as clocksoure it also must run NTP in some way to
>> >> > avoid the potential drift what will most likely happen, independent of
>> >> > any migration.    
>> >> Which drift? While anyone's well advised to run NTP, a completely
>> >> isolated set of systems may have no need to, if their interactions don't
>> >> depend on exactly matching time.  
>> > 
>> > If these hosts do not sync time to some reference host, the advancing of 
>> > time
>> > is undefined before and after my change.  
>> 
>> I'm lost. I simply don't understand what you're trying to tell me,
>> or how your answer relates to my question.
> 
> Then please rephrase the question?

I was asking the drift of what you are talking about.

> I do not see how my path affects the
> advancing of time in domUs running on isolated systems. If their hardware
> clocks advance at the same speed, my patch will not affect it. And if they
> do advance at a different speed, what can emulation do to help with 
> "correctness"?

In a first step, let's assume clock calibration produces a precise result.
In such a case, are we in agreement that emulation is needed after
migration if clock speeds differ, even if just slightly?

In a second step, let's consider what impact errors in calibration have.
Between two systems with exactly the same hardware crystal
frequency there of course is going to be some drift. The problem
though is - between the two calibrated clock values from two systems
you can't easily tell what part of the difference is a result of the
calibration being imprecise, and what part of it is because of the
crystals not providing the exact same frequency. Without knowing
the possible range of both errors, the argumentation of _one of
them_ being tolerable within a certain range to consider _both_
systems sufficiently equal is at least questionable.

And further argumentation that everyone is using NTP anyway
doesn't make it any better, when it's no-where written down that
Xen is unusable with NTP running in all guests (I'm exaggerating
here just to get the point over). Don't forget that e.g. with
XenoLinux'es independent-wallclock setting defaulting to false, we've
been suggesting that people _don't_ need to use NTP inside their
(admittedly PV) guests. IOW - your change may not break people
not using NTP. Hence I don't think the mode you introduce can be
a default-on one, which in turn means a per-domain or at least
global enable control is needed (as over previous iterations we
seem to have been agreeing).

Jan



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel