0001 .. SPDX-License-Identifier: GPL-2.0
0002
0003 Clocks and Timers
0004 =================
0005
0006 arm64
0007 -----
0008 On arm64, Hyper-V virtualizes the ARMv8 architectural system counter
0009 and timer. Guest VMs use this virtualized hardware as the Linux
0010 clocksource and clockevents via the standard arm_arch_timer.c
0011 driver, just as they would on bare metal. Linux vDSO support for the
0012 architectural system counter is functional in guest VMs on Hyper-V.
0013 While Hyper-V also provides a synthetic system clock and four synthetic
0014 per-CPU timers as described in the TLFS, they are not used by the
0015 Linux kernel in a Hyper-V guest on arm64. However, older versions
0016 of Hyper-V for arm64 only partially virtualize the ARMv8
0017 architectural timer, such that the timer does not generate
0018 interrupts in the VM. Because of this limitation, running current
0019 Linux kernel versions on these older Hyper-V versions requires an
0020 out-of-tree patch to use the Hyper-V synthetic clocks/timers instead.
0021
0022 x86/x64
0023 -------
0024 On x86/x64, Hyper-V provides guest VMs with a synthetic system clock
0025 and four synthetic per-CPU timers as described in the TLFS. Hyper-V
0026 also provides access to the virtualized TSC via the RDTSC and
0027 related instructions. These TSC instructions do not trap to
0028 the hypervisor and so provide excellent performance in a VM.
0029 Hyper-V performs TSC calibration, and provides the TSC frequency
0030 to the guest VM via a synthetic MSR. Hyper-V initialization code
0031 in Linux reads this MSR to get the frequency, so it skips TSC
0032 calibration and sets tsc_reliable. Hyper-V provides virtualized
0033 versions of the PIT (in Hyper-V Generation 1 VMs only), local
0034 APIC timer, and RTC. Hyper-V does not provide a virtualized HPET in
0035 guest VMs.
0036
0037 The Hyper-V synthetic system clock can be read via a synthetic MSR,
0038 but this access traps to the hypervisor. As a faster alternative,
0039 the guest can configure a memory page to be shared between the guest
0040 and the hypervisor. Hyper-V populates this memory page with a
0041 64-bit scale value and offset value. To read the synthetic clock
0042 value, the guest reads the TSC and then applies the scale and offset
0043 as described in the Hyper-V TLFS. The resulting value advances
0044 at a constant 10 MHz frequency. In the case of a live migration
0045 to a host with a different TSC frequency, Hyper-V adjusts the
0046 scale and offset values in the shared page so that the 10 MHz
0047 frequency is maintained.
0048
0049 Starting with Windows Server 2022 Hyper-V, Hyper-V uses hardware
0050 support for TSC frequency scaling to enable live migration of VMs
0051 across Hyper-V hosts where the TSC frequency may be different.
0052 When a Linux guest detects that this Hyper-V functionality is
0053 available, it prefers to use Linux's standard TSC-based clocksource.
0054 Otherwise, it uses the clocksource for the Hyper-V synthetic system
0055 clock implemented via the shared page (identified as
0056 "hyperv_clocksource_tsc_page").
0057
0058 The Hyper-V synthetic system clock is available to user space via
0059 vDSO, and gettimeofday() and related system calls can execute
0060 entirely in user space. The vDSO is implemented by mapping the
0061 shared page with scale and offset values into user space. User
0062 space code performs the same algorithm of reading the TSC and
0063 appying the scale and offset to get the constant 10 MHz clock.
0064
0065 Linux clockevents are based on Hyper-V synthetic timer 0. While
0066 Hyper-V offers 4 synthetic timers for each CPU, Linux only uses
0067 timer 0. Interrupts from stimer0 are recorded on the "HVS" line in
0068 /proc/interrupts. Clockevents based on the virtualized PIT and
0069 local APIC timer also work, but the Hyper-V synthetic timer is
0070 preferred.
0071
0072 The driver for the Hyper-V synthetic system clock and timers is
0073 drivers/clocksource/hyperv_timer.c.
