| .. SPDX-License-Identifier: GPL-2.0 |
| |
| Clocks and Timers |
| ================= |
| |
| arm64 |
| ----- |
| On arm64, Hyper-V virtualizes the ARMv8 architectural system counter |
| and timer. Guest VMs use this virtualized hardware as the Linux |
| clocksource and clockevents via the standard arm_arch_timer.c |
| driver, just as they would on bare metal. Linux vDSO support for the |
| architectural system counter is functional in guest VMs on Hyper-V. |
| While Hyper-V also provides a synthetic system clock and four synthetic |
| per-CPU timers as described in the TLFS, they are not used by the |
| Linux kernel in a Hyper-V guest on arm64. However, older versions |
| of Hyper-V for arm64 only partially virtualize the ARMv8 |
| architectural timer, such that the timer does not generate |
| interrupts in the VM. Because of this limitation, running current |
| Linux kernel versions on these older Hyper-V versions requires an |
| out-of-tree patch to use the Hyper-V synthetic clocks/timers instead. |
| |
| x86/x64 |
| ------- |
| On x86/x64, Hyper-V provides guest VMs with a synthetic system clock |
| and four synthetic per-CPU timers as described in the TLFS. Hyper-V |
| also provides access to the virtualized TSC via the RDTSC and |
| related instructions. These TSC instructions do not trap to |
| the hypervisor and so provide excellent performance in a VM. |
| Hyper-V performs TSC calibration, and provides the TSC frequency |
| to the guest VM via a synthetic MSR. Hyper-V initialization code |
| in Linux reads this MSR to get the frequency, so it skips TSC |
| calibration and sets tsc_reliable. Hyper-V provides virtualized |
| versions of the PIT (in Hyper-V Generation 1 VMs only), local |
| APIC timer, and RTC. Hyper-V does not provide a virtualized HPET in |
| guest VMs. |
| |
| The Hyper-V synthetic system clock can be read via a synthetic MSR, |
| but this access traps to the hypervisor. As a faster alternative, |
| the guest can configure a memory page to be shared between the guest |
| and the hypervisor. Hyper-V populates this memory page with a |
| 64-bit scale value and offset value. To read the synthetic clock |
| value, the guest reads the TSC and then applies the scale and offset |
| as described in the Hyper-V TLFS. The resulting value advances |
| at a constant 10 MHz frequency. In the case of a live migration |
| to a host with a different TSC frequency, Hyper-V adjusts the |
| scale and offset values in the shared page so that the 10 MHz |
| frequency is maintained. |
| |
| Starting with Windows Server 2022 Hyper-V, Hyper-V uses hardware |
| support for TSC frequency scaling to enable live migration of VMs |
| across Hyper-V hosts where the TSC frequency may be different. |
| When a Linux guest detects that this Hyper-V functionality is |
| available, it prefers to use Linux's standard TSC-based clocksource. |
| Otherwise, it uses the clocksource for the Hyper-V synthetic system |
| clock implemented via the shared page (identified as |
| "hyperv_clocksource_tsc_page"). |
| |
| The Hyper-V synthetic system clock is available to user space via |
| vDSO, and gettimeofday() and related system calls can execute |
| entirely in user space. The vDSO is implemented by mapping the |
| shared page with scale and offset values into user space. User |
| space code performs the same algorithm of reading the TSC and |
| applying the scale and offset to get the constant 10 MHz clock. |
| |
| Linux clockevents are based on Hyper-V synthetic timer 0 (stimer0). |
| While Hyper-V offers 4 synthetic timers for each CPU, Linux only uses |
| timer 0. In older versions of Hyper-V, an interrupt from stimer0 |
| results in a VMBus control message that is demultiplexed by |
| vmbus_isr() as described in the Documentation/virt/hyperv/vmbus.rst |
| documentation. In newer versions of Hyper-V, stimer0 interrupts can |
| be mapped to an architectural interrupt, which is referred to as |
| "Direct Mode". Linux prefers to use Direct Mode when available. Since |
| x86/x64 doesn't support per-CPU interrupts, Direct Mode statically |
| allocates an x86 interrupt vector (HYPERV_STIMER0_VECTOR) across all CPUs |
| and explicitly codes it to call the stimer0 interrupt handler. Hence |
| interrupts from stimer0 are recorded on the "HVS" line in /proc/interrupts |
| rather than being associated with a Linux IRQ. Clockevents based on the |
| virtualized PIT and local APIC timer also work, but Hyper-V stimer0 |
| is preferred. |
| |
| The driver for the Hyper-V synthetic system clock and timers is |
| drivers/clocksource/hyperv_timer.c. |