#Docker for mac host code

Unfortunately the amework on the Mac does not provide enough information (particularly over suspend/resume) to allow the implementation of such a paravirtualised timesource so we reported the issue to Apple and searched for a workaround. Many hypervisors fix these problems by providing an explicit “paravirtualised clock” interface, providing enough additional information to the VM to allow it to correctly convert a TSC value to seconds. The unreliability of using TSC counters can be seen on this Docker Desktop for Mac install: $ docker run -rm -privileged alpine /bin/dmesg | grep clocksource … clocksource: Switched to clocksource tsc clocksource: timekeeping watchdog on CPU3: Marking clocksource 'tsc' as unstable because the skew is too large: clocksource: 'hpet' wd_now: 388d8fc2 wd_last: 377f3b7c mask: ffffffff clocksource: 'tsc' cs_now: 104a0911ec5a cs_last: 10492ccc2aec mask: ffffffffffffffff clocksource: Switched to clocksource hpet

When a virtual CPU is stopped executing on one physical CPU core and later starts executing on another one, the TSC counter can suddenly jump forwards or backwards.

The counter can jump back to 0 when the physical CPU is reset, for example over a host suspend / resume.

Some power management technology will change the TSC frequency dynamically.

There is no reliable way to discover the TSC frequency : without this we don’t know what to divide the counter values by to transform the result into seconds.

However there are problems when we try to use these counters long-term as a reliable source of absolute physical time, particularly when running in a VM:

#Docker for mac host code

The two values can then be subtracted to yield the time the code took to run in CPU cycles. TSC counters are frequently used for benchmarking, where the current TSC value is read (via the rdtsc instruction) at the beginning and then again at the end of a test run. The most reliable is usually the CPU Time Stamp Counter (“tsc”) clocksource which measures time by counting the number of CPU cycles since the last CPU reset.

Unfortunately reading the RTC is a slow operation (both on physical hardware and virtual) so the Linux kernel builds its own internal clock on top of other sources of timing information, known as clocksources. When the helper VM boots the clocks are initially synchronised by an explicit invocation of “hwclock -s” which reads the virtual RTC in HyperKit. Wait, doesn’t the VM have a (virtual) hardware Real Time Clock (RTC)?

Time drift can be very frustrating as you can see by reading issues such as. For example “make” will stop working properly across shared volumes (“docker run -v”) when the modification times on source files (typically written on the host) are older than the modification times on the binaries (typically written in the VM) even after the source files are changed. When the two clocks drift apart then suddenly commands which rely on the time, or on file timestamps, may start to behave differently. The helper VM has its own internal clock, separate from the host’s clock. Docker Desktop for Mac runs the Docker engine and Linux containers in a helper LinuxKit VM since macOS doesn’t have native container support.