Lines Matching full:the
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
6 * counter, etc.) and real time. It is designed to address the problem of
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
12 * counter will change within the tolerances of its specification (typically
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.
17 * Second, there may be a step change in the value of the counter itself, as
18 * its accuracy is limited by the precision of the NTP synchronization on the
21 * So any calibration (NTP, PTP, etc.) which the guest has done on the source
22 * host before migration is invalid, and needs to be redone on the new host.
24 * In its most basic mode, this structure provides only an indication to the
25 * guest that live migration has occurred. This allows the guest to know that
27 * reliable accurate timestamps (e.g. distributed databases), the structure
28 * can be mapped all the way to userspace. This allows the application to see
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
33 * In its more advanced mode. this structure can also be used to expose the
34 * precise relationship of the CPU counter to real time, as calibrated by the
37 * and wait for NTP to recover. This mode does, of course, rely on the
43 * actually messes with the apparent counter *period*. A linear smearing
44 * of 1 ms per second would effectively tweak the counter period by 1000PPM
45 * at the start/end of the smearing period, while a sinusoidal smear would
48 * This structure is offered with the intent that it be adopted into the
49 * nascent virtio-rtc standard, as a virtio-rtc that does not address the live
51 * reason, certain fields use precisely the same numeric definitions as in
52 * the virtio-rtc proposal. The structure can also be exposed through an ACPI
53 * device with the CID "VMCLOCK", modelled on the "VMGENID" device except for
54 * the fact that it uses a real _CRS to convey the address of the structure
83 * This field changes to another non-repeating value when the CPU
85 * the guest know that it should discard any calibration it has
86 * performed of the counter against external sources (NTP/PTP/etc.).
90 /* Indicates that the tai_offset_sec field is valid */
96 * indicate the approximate imminence of the event.
105 * If the MONOTONIC flag is set then (other than leap seconds) it is
106 * guaranteed that the time calculated according this structure at
107 * any given moment shall never appear to be later than the time
108 * calculated via the structure at any *later* moment.
111 * immediately after setting the low bit of seq_count (and the
112 * associated memory barrier), using the previously-valid time and
114 * a counter reading taken immediately before *clearing* the low
115 * bit again after the update, using the about-to-be-valid fields.
128 * The time exposed through this device is never smeared. This field
129 * corresponds to the 'subtype' field in virtio-rtc, which indicates
130 * the smearing method. However in this case it provides a *hint* to
131 * the guest operating system, such that *if* the guest OS wants to
133 * UTC, it may do so in a fashion consistent with the other systems
134 * in the nearby environment.
143 * This field is based on the VIRTIO_RTC_LEAP_xxx values as defined
144 * in the current draft of virtio-rtc, but since smearing cannot be
145 * used with the shared memory device, some values are not used.
147 * The _POST_POS and _POST_NEG values allow the guest to perform
148 * its own smearing during the day or so after a leap second when
166 * Counter period, and error margin of same. The unit of these