Lines Matching +full:clock +full:- +full:frequency

1 /* SPDX-License-Identifier: ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) */
4 * This structure provides a vDSO-style clock to VM guests, exposing the
5 * relationship (or lack thereof) between the CPU clock (TSC, timebase, arch
7 * live migration, which other clock enlightenments do not.
9 * When a guest is live migrated, this affects the clock in two ways.
11 * First, even between identical hosts the actual frequency of the underlying
13 * ±50PPM, or 4 seconds a day). This frequency also varies over time on the
15 * live migration there is a step change in the frequency, with no warning.
26 * its clock is invalid and take remedial action. For applications that need
29 * directly for itself that the clock is disrupted and take appropriate
30 * action, even when using a vDSO-style method to get the time instead of a
41 * guest wishes to construct a smeared clock, it can do so. Presenting a
42 * smeared clock through this interface would be problematic because it
49 * nascent virtio-rtc standard, as a virtio-rtc that does not address the live
52 * the virtio-rtc proposal. The structure can also be exposed through an ACPI
61 #include "standard-headers/linux/types.h"
74 #define VMCLOCK_TIME_UTC 0 /* Since 1970-01-01 00:00:00z */
75 #define VMCLOCK_TIME_TAI 1 /* Since 1970-01-01 00:00:00z */
80 /* NON-CONSTANT FIELDS PROTECTED BY SEQCOUNT LOCK */
83 * This field changes to another non-repeating value when the CPU
94 * A guest which provides latency-sensitive services may wish to
112 * associated memory barrier), using the previously-valid time and
115 * bit again after the update, using the about-to-be-valid fields.
129 * corresponds to the 'subtype' field in virtio-rtc, which indicates
132 * provide its users with an alternative clock which does not follow
144 * in the current draft of virtio-rtc, but since smearing cannot be