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