Re: [PATCH v12] tolerate jitter in cpu_khz calculation to avoid TSC emulation

From: Olaf Hering <olaf@aepfle.de>
To: Jan Beulich <JBeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>,
	Wei Liu <wei.liu2@citrix.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [PATCH v12] tolerate jitter in cpu_khz calculation to avoid TSC emulation
Date: Tue, 12 Mar 2019 11:03:59 +0100	[thread overview]
Message-ID: <20190312110359.56532ab3.olaf@aepfle.de> (raw)
In-Reply-To: <5C863567020000780021D1FE@prv1-mh.provo.novell.com>

[-- Attachment #1.1: Type: text/plain, Size: 1928 bytes --]

Am Mon, 11 Mar 2019 04:16:07 -0600
schrieb "Jan Beulich" <JBeulich@suse.com>:

> >>> On 08.03.19 at 20:20, <olaf@aepfle.de> wrote:  
> > To reiterate the second paragraph: if a domU uses TSC as primary clock
> > source, it is expected that it runs NTP to cover for the resulting
> > drift. Therefore this change does no need a knob to turn it on or off.  
> 
> Did you omit a 't' or a 'w' above? Judging from the patch I think you
> mean "not", but I don't see how this follows, especially with your
> subsequent reply validly stating that such a requirement did not
> exist with the XenoLinux kernels. And please don't forget that
> Linux is not the only possible guest OS. What is or is not a
> requirement inside the guest depends not only on Xen's behavior,
> but also on the OS'es. Hence uniformly (and even by default)
> changing the behavior for everyone is imo not acceptable.

If I interpret the various docs, which are available online, correctly
there is always a recommendation to sync with an external clocksource,
IF the system clock has to be somewhat accurate.
For example the XenServer docs mentions that for Windows, PV and HVM.
If that external source is a pvclock driver, then it just means the
syncing has to be done by dom0. I have not verified it, but I think
NTP in dom0 will sync Xen, which in turn allows pvclock to sync domU.

The change exchanges one sort of inaccuracy with another. In other words,
it was broken before and will remain broken after migration/restore.

> > +#define VTSC_JITTER_RANGE_KHZ 200UL   /* Assumed jitter in cpu_khz */  
> I'm struggling to understand the comment: Surely not every single
> CPU surfaces a jitter of precisely 200kHz?

I think that variable describes something like 'range' or 'dispersion'
of measurement results, of something that can not be measured accurately.
So VTSC_MEASUREMENT_INACCURACY_RANGE_KHZ may work.

Olaf

[-- Attachment #1.2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

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