TSC calibration in virtual machines

[Alan Somers]

On Wed, Jun 27, 2018 at 11:05 AM, Jung-uk Kim <jkim at freebsd.org> wrote:

> On 06/27/2018 12:47, Alan Somers wrote:
> > On Wed, Jun 27, 2018 at 10:36 AM, Jung-uk Kim <jkim at freebsd.org
> > <mailto:jkim at freebsd.org>> wrote:
> >
> >     On 06/27/2018 03:14, Andriy Gapon wrote:
> >     >
> >     > It seems that TSC calibration in virtual machines sometimes can do
> more harm
> >     > than good.  Should we default to trusting the information provided
> by a hypervisor?
> >     >
> >     > Specifically, I am observing a problem on GCE instances where
> calibrated TSC
> >     > frequency is about 10% lower than advertised frequency.  And
> apparently the
> >     > advertised frequency is the right one.
> >     >
> >     > I found this thread with similar reports and a variety of
> workarounds from
> >     > administratively disabling the calibration to switching to a
> different timecounter:
> >     > https://lists.freebsd.org/pipermail/freebsd-cloud/2017-
> January/000080.html
> >     <https://lists.freebsd.org/pipermail/freebsd-cloud/2017-
> January/000080.html>
> >
> >     We already do that for VMware hosts since r221214.
> >
> >     https://svnweb.freebsd.org/changeset/base/221214
> >     <https://svnweb.freebsd.org/changeset/base/221214>
> >
> >     We should do the same for each hypervisor.
> >
> > We probably should.  But why does calibration fail in the first place?
> Because multiple guests are sharing same physical CPUs and guest OS has
> no control, timing cannot be 100% accurate.
>
> > If it can fail in a VM, then it can probably fail on bare metal too.  It
> > would be worth investigating.
> It does not "fail" in bare metal because we have almost complete control.
>
> Jung-uk Kim
>
>
Makes sense.  I didn't realize that it ran before the scheduler or
interrupts were started.