* [PATCH v11 01/23] KVM: x86: Improve synchronization in kvm_synchronize_tsc()
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 15:49 ` [PATCH v11 02/23] KVM: x86: Kill last_tsc_{nsec,write,offset} fields David Woodhouse
` (21 subsequent siblings)
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
When synchronizing to an existing TSC (either by explicitly writing
zero, or the legacy hack where the TSC is written within one second's
worth of the previously written TSC), the last_tsc_write and
last_tsc_nsec values were being misrecorded by __kvm_synchronize_tsc().
The *unsynchronized* value of the TSC (perhaps even zero) was being
recorded, along with the current time at which kvm_synchronize_tsc()
was called. This could cause *subsequent* writes to fail to synchronize
correctly.
Fix that by extrapolating the generation's TSC value to the current
time (data = cur_tsc_write + elapsed cycles) before passing it to
__kvm_synchronize_tsc(), so the recorded {data, ns} pair always lies
on the generation's line and the one-second matching window slides
forward with each synchronized write. When the TSC is stable, reuse
the generation's offset exactly; when it is unstable, compute a new
offset for the extrapolated value.
Furthermore, there were *three* different TSC reads used for calculating
the "current" time, all slightly different from each other. Fix that by
using kvm_get_time_and_clockread() where possible and using the same
host_tsc value in all cases.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
---
arch/x86/kvm/x86.c | 39 ++++++++++++++++++++++++++++++---------
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 32563a91fba9..7a2b0b99373f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -210,6 +210,10 @@ module_param(pi_inject_timer, bint, 0644);
static bool __read_mostly mitigate_smt_rsb;
module_param(mitigate_smt_rsb, bool, 0444);
+#ifdef CONFIG_X86_64
+static bool kvm_get_time_and_clockread(s64 *kernel_ns, u64 *tsc_timestamp);
+#endif
+
#define KVM_SUPPORTED_XCR0 (XFEATURE_MASK_FP | XFEATURE_MASK_SSE \
| XFEATURE_MASK_YMM | XFEATURE_MASK_BNDREGS \
| XFEATURE_MASK_BNDCSR | XFEATURE_MASK_AVX512 \
@@ -1374,14 +1378,23 @@ void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value)
{
u64 data = user_value ? *user_value : 0;
struct kvm *kvm = vcpu->kvm;
- u64 offset, ns, elapsed;
+ u64 offset, host_tsc, elapsed;
+ s64 ns;
unsigned long flags;
bool matched = false;
bool synchronizing = false;
raw_spin_lock_irqsave(&kvm->arch.tsc_write_lock, flags);
- offset = kvm_compute_l1_tsc_offset(vcpu, rdtsc(), data);
- ns = get_kvmclock_base_ns();
+
+#ifdef CONFIG_X86_64
+ if (!kvm_get_time_and_clockread(&ns, &host_tsc))
+#endif
+ {
+ host_tsc = rdtsc();
+ ns = get_kvmclock_base_ns();
+ }
+
+ offset = kvm_compute_l1_tsc_offset(vcpu, host_tsc, data);
elapsed = ns - kvm->arch.last_tsc_nsec;
if (vcpu->arch.virtual_tsc_khz) {
@@ -1424,13 +1437,21 @@ void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value)
*/
if (synchronizing &&
vcpu->arch.virtual_tsc_khz == kvm->arch.last_tsc_khz) {
- if (!kvm_check_tsc_unstable()) {
+ /*
+ * If synchronizing, advance the reference point to "now"
+ * so the matching window slides forward with each vCPU.
+ * Extrapolate from the generation's own origin: 'elapsed'
+ * is measured from the most recent write, which lies on
+ * the generation's line only for the first matched write.
+ */
+ u64 delta = nsec_to_cycles(vcpu, ns - kvm->arch.cur_tsc_nsec);
+
+ data = kvm->arch.cur_tsc_write + delta;
+
+ if (!kvm_check_tsc_unstable())
offset = kvm->arch.cur_tsc_offset;
- } else {
- u64 delta = nsec_to_cycles(vcpu, elapsed);
- data += delta;
- offset = kvm_compute_l1_tsc_offset(vcpu, rdtsc(), data);
- }
+ else
+ offset = kvm_compute_l1_tsc_offset(vcpu, host_tsc, data);
matched = true;
}
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v11 02/23] KVM: x86: Kill last_tsc_{nsec,write,offset} fields
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
2026-11-05 15:49 ` [PATCH v11 01/23] KVM: x86: Improve synchronization in kvm_synchronize_tsc() David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 16:47 ` sashiko-bot
2026-11-05 15:49 ` [PATCH v11 03/23] KVM: x86: Replace nr_vcpus_matched_tsc count with all_vcpus_matched_tsc bool David Woodhouse
` (20 subsequent siblings)
22 siblings, 1 reply; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
These pointlessly duplicate the cur_tsc_{nsec,write,offset} values.
The only place they were used was where the TSC is stable and a new
vCPU is being synchronized to the previous setting, in which case the
cur_tsc_* value is definitely identical.
Rename last_tsc_khz and last_tsc_scaling_ratio to cur_tsc_khz and
cur_tsc_scaling_ratio respectively, since they are properties of the
current TSC generation.
Since cur_tsc_offset now serves as the single source of truth for the
TSC generation's offset, the backwards-TSC adjustment (used during S4
resume when the host TSC resets) must also update cur_tsc_offset by
the same delta applied to all vCPUs (scaled to the guest TSC rate, as
adjust_tsc_offset_host() does). Without this, subsequent vCPUs that
synchronize after the adjustment would get the stale pre-S4 offset.
Since a synchronization now establishes an absolute offset which (via
a matched reuse of cur_tsc_offset) already includes any backwards-TSC
delta, clear the vCPU's pending tsc_offset_adjustment when writing it:
the deferred per-vCPU compensation would otherwise be applied on top
at the next vcpu_load, doubling the delta. Previously this could not
happen, because zeroing the last_tsc values disabled offset matching
entirely after a backwards TSC.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
---
Documentation/virt/kvm/locking.rst | 2 +-
arch/x86/include/asm/kvm_host.h | 7 +--
arch/x86/kvm/x86.c | 72 ++++++++++++++++++------------
3 files changed, 47 insertions(+), 34 deletions(-)
diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst
index 662231e958a0..4548b61a7652 100644
--- a/Documentation/virt/kvm/locking.rst
+++ b/Documentation/virt/kvm/locking.rst
@@ -263,7 +263,7 @@ time it will be set using the Dirty tracking mechanism described above.
:Type: raw_spinlock_t
:Arch: x86
-:Protects: - kvm_arch::{last_tsc_write,last_tsc_nsec,last_tsc_offset}
+:Protects: - kvm_arch::{cur_tsc_write,cur_tsc_nsec,cur_tsc_offset}
- tsc offset in vmcb
:Comment: 'raw' because updating the tsc offsets must not be preempted.
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index e2eef7057bd3..ea48b1949316 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1236,11 +1236,8 @@ struct kvm_arch {
* preemption-disabled region, so it must be a raw spinlock.
*/
raw_spinlock_t tsc_write_lock;
- u64 last_tsc_nsec;
- u64 last_tsc_write;
- u32 last_tsc_khz;
- u64 last_tsc_offset;
- u64 last_tsc_scaling_ratio;
+ u32 cur_tsc_khz;
+ u64 cur_tsc_scaling_ratio;
u64 cur_tsc_nsec;
u64 cur_tsc_write;
u64 cur_tsc_offset;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 7a2b0b99373f..90f9b07ef749 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1334,17 +1334,24 @@ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc,
vcpu->kvm->arch.user_set_tsc = true;
/*
- * We also track th most recent recorded KHZ, write and time to
- * allow the matching interval to be extended at each write.
+ * Track the TSC frequency, scaling ratio, and offset for the current
+ * generation. These are used to detect matching TSC writes and to
+ * compute the guest TSC from the host clock.
*/
- kvm->arch.last_tsc_nsec = ns;
- kvm->arch.last_tsc_write = tsc;
- kvm->arch.last_tsc_khz = vcpu->arch.virtual_tsc_khz;
- kvm->arch.last_tsc_offset = offset;
- kvm->arch.last_tsc_scaling_ratio = vcpu->arch.l1_tsc_scaling_ratio;
+ kvm->arch.cur_tsc_khz = vcpu->arch.virtual_tsc_khz;
+ kvm->arch.cur_tsc_scaling_ratio = vcpu->arch.l1_tsc_scaling_ratio;
vcpu->arch.last_guest_tsc = tsc;
+ /*
+ * The offset written below is absolute, superseding any backwards-TSC
+ * compensation still pending from kvm_arch_enable_virtualization_cpu()
+ * (which has already been folded into cur_tsc_offset, and thus into
+ * a matched @offset); applying it again at the next vcpu_load would
+ * double it.
+ */
+ vcpu->arch.tsc_offset_adjustment = 0;
+
kvm_vcpu_write_tsc_offset(vcpu, offset);
if (!matched) {
@@ -1354,8 +1361,6 @@ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc,
* nanosecond time, offset, and write, so if TSCs are in
* sync, we can match exact offset, and if not, we can match
* exact software computation in compute_guest_tsc()
- *
- * These values are tracked in kvm->arch.cur_xxx variables.
*/
kvm->arch.cur_tsc_generation++;
kvm->arch.cur_tsc_nsec = ns;
@@ -1395,7 +1400,7 @@ void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value)
}
offset = kvm_compute_l1_tsc_offset(vcpu, host_tsc, data);
- elapsed = ns - kvm->arch.last_tsc_nsec;
+ elapsed = ns - kvm->arch.cur_tsc_nsec;
if (vcpu->arch.virtual_tsc_khz) {
if (data == 0) {
@@ -1405,7 +1410,7 @@ void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value)
*/
synchronizing = true;
} else if (kvm->arch.user_set_tsc) {
- u64 tsc_exp = kvm->arch.last_tsc_write +
+ u64 tsc_exp = kvm->arch.cur_tsc_write +
nsec_to_cycles(vcpu, elapsed);
u64 tsc_hz = vcpu->arch.virtual_tsc_khz * 1000LL;
/*
@@ -1436,15 +1441,12 @@ void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value)
* it's better to try to match offsets from the beginning.
*/
if (synchronizing &&
- vcpu->arch.virtual_tsc_khz == kvm->arch.last_tsc_khz) {
+ vcpu->arch.virtual_tsc_khz == kvm->arch.cur_tsc_khz) {
/*
* If synchronizing, advance the reference point to "now"
* so the matching window slides forward with each vCPU.
- * Extrapolate from the generation's own origin: 'elapsed'
- * is measured from the most recent write, which lies on
- * the generation's line only for the first matched write.
*/
- u64 delta = nsec_to_cycles(vcpu, ns - kvm->arch.cur_tsc_nsec);
+ u64 delta = nsec_to_cycles(vcpu, elapsed);
data = kvm->arch.cur_tsc_write + delta;
@@ -1615,7 +1617,7 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
* get_kvmclock() to compute kvmclock from the host TSC
* without needing a vCPU reference.
*/
- ka->master_tsc_scaling_ratio = ka->last_tsc_scaling_ratio;
+ ka->master_tsc_scaling_ratio = ka->cur_tsc_scaling_ratio;
tsc_hz = (u64)get_cpu_tsc_khz() * HZ_PER_KHZ;
if (tsc_hz && kvm_caps.has_tsc_control)
tsc_hz = kvm_scale_tsc(tsc_hz,
@@ -3344,8 +3346,8 @@ static int kvm_arch_tsc_set_attr(struct kvm_vcpu *vcpu,
raw_spin_lock_irqsave(&kvm->arch.tsc_write_lock, flags);
matched = (vcpu->arch.virtual_tsc_khz &&
- kvm->arch.last_tsc_khz == vcpu->arch.virtual_tsc_khz &&
- kvm->arch.last_tsc_offset == offset);
+ kvm->arch.cur_tsc_khz == vcpu->arch.virtual_tsc_khz &&
+ kvm->arch.cur_tsc_offset == offset);
tsc = kvm_scale_tsc(rdtsc(), vcpu->arch.l1_tsc_scaling_ratio) + offset;
ns = get_kvmclock_base_ns();
@@ -9803,7 +9805,7 @@ int kvm_arch_enable_virtualization_cpu(void)
{
struct kvm *kvm;
struct kvm_vcpu *vcpu;
- unsigned long i;
+ unsigned long i, flags;
int ret;
u64 local_tsc;
u64 max_tsc = 0;
@@ -9874,6 +9876,24 @@ int kvm_arch_enable_virtualization_cpu(void)
if (backwards_tsc) {
u64 delta_cyc = max_tsc - local_tsc;
list_for_each_entry(kvm, &vm_list, vm_list) {
+ /*
+ * Hold tsc_write_lock across the per-vCPU adjustments
+ * AND the generation reference offset adjustment, so
+ * that a concurrent TSC synchronization cannot observe
+ * one without the other (it would compute an offset
+ * with the delta applied twice, or not at all).
+ *
+ * The generation's reference offset is adjusted by the
+ * same (guest-scaled, as adjust_tsc_offset_host()
+ * does for each vCPU) delta, so that future
+ * KVM_SET_TSC / vCPU creation still matches against
+ * the adjusted TSC timeline. The recorded
+ * {cur_tsc_nsec, cur_tsc_write} pair needs no
+ * adjustment: the guest TSC is kept continuous
+ * across the host TSC jump, and that pair lives in
+ * the wall-clock/guest-cycle domain.
+ */
+ raw_spin_lock_irqsave(&kvm->arch.tsc_write_lock, flags);
kvm->arch.backwards_tsc_observed = true;
kvm_for_each_vcpu(i, vcpu, kvm) {
vcpu->arch.tsc_offset_adjustment += delta_cyc;
@@ -9881,14 +9901,10 @@ int kvm_arch_enable_virtualization_cpu(void)
kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu);
}
- /*
- * We have to disable TSC offset matching.. if you were
- * booting a VM while issuing an S4 host suspend....
- * you may have some problem. Solving this issue is
- * left as an exercise to the reader.
- */
- kvm->arch.last_tsc_nsec = 0;
- kvm->arch.last_tsc_write = 0;
+ kvm->arch.cur_tsc_offset +=
+ kvm_scale_tsc(delta_cyc,
+ kvm->arch.cur_tsc_scaling_ratio);
+ raw_spin_unlock_irqrestore(&kvm->arch.tsc_write_lock, flags);
}
}
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v11 02/23] KVM: x86: Kill last_tsc_{nsec,write,offset} fields
2026-11-05 15:49 ` [PATCH v11 02/23] KVM: x86: Kill last_tsc_{nsec,write,offset} fields David Woodhouse
@ 2026-11-05 16:47 ` sashiko-bot
0 siblings, 0 replies; 33+ messages in thread
From: sashiko-bot @ 2026-11-05 16:47 UTC (permalink / raw)
To: David Woodhouse, kvm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] KVM: x86: cur_tsc_nsec diverges from cur_tsc_offset after backwards TSC
--
commit 12f55d317226d504abbc980263077a541c5123db
Author: David Woodhouse <dwmw@amazon.co.uk>
KVM: x86: Kill last_tsc_{nsec,write,offset} fields
This commit removes the redundant last_tsc_{nsec,write,offset} fields from
struct kvm_arch and renames last_tsc_{khz,scaling_ratio} to
cur_tsc_{khz,scaling_ratio}. It also updates kvm->arch.cur_tsc_offset during
backwards-TSC compensation on resume and clears pending per-vCPU
tsc_offset_adjustment during TSC synchronization.
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 7a2b0b99373fe..90f9b07ef7491 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
[ ... ]
> @@ -1395,7 +1400,7 @@ void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value)
> }
>
> offset = kvm_compute_l1_tsc_offset(vcpu, host_tsc, data);
> - elapsed = ns - kvm->arch.last_tsc_nsec;
> + elapsed = ns - kvm->arch.cur_tsc_nsec;
>
> if (vcpu->arch.virtual_tsc_khz) {
> if (data == 0) {
> @@ -1405,7 +1410,7 @@ void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value)
> */
> synchronizing = true;
> } else if (kvm->arch.user_set_tsc) {
> - u64 tsc_exp = kvm->arch.last_tsc_write +
> + u64 tsc_exp = kvm->arch.cur_tsc_write +
> nsec_to_cycles(vcpu, elapsed);
> u64 tsc_hz = vcpu->arch.virtual_tsc_khz * 1000LL;
> /*
> @@ -1436,15 +1441,12 @@ void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value)
> * it's better to try to match offsets from the beginning.
> */
> if (synchronizing &&
> - vcpu->arch.virtual_tsc_khz == kvm->arch.last_tsc_khz) {
> + vcpu->arch.virtual_tsc_khz == kvm->arch.cur_tsc_khz) {
> /*
> * If synchronizing, advance the reference point to "now"
> * so the matching window slides forward with each vCPU.
> - * Extrapolate from the generation's own origin: 'elapsed'
> - * is measured from the most recent write, which lies on
> - * the generation's line only for the first matched write.
> */
> - u64 delta = nsec_to_cycles(vcpu, ns - kvm->arch.cur_tsc_nsec);
> + u64 delta = nsec_to_cycles(vcpu, elapsed);
>
> data = kvm->arch.cur_tsc_write + delta;
[ ... ]
> @@ -9874,6 +9876,24 @@ int kvm_arch_enable_virtualization_cpu(void)
> if (backwards_tsc) {
> u64 delta_cyc = max_tsc - local_tsc;
> list_for_each_entry(kvm, &vm_list, vm_list) {
> + /*
> + * Hold tsc_write_lock across the per-vCPU adjustments
> + * AND the generation reference offset adjustment, so
> + * that a concurrent TSC synchronization cannot observe
> + * one without the other (it would compute an offset
> + * with the delta applied twice, or not at all).
> + *
> + * The generation's reference offset is adjusted by the
> + * same (guest-scaled, as adjust_tsc_offset_host()
> + * does for each vCPU) delta, so that future
> + * KVM_SET_TSC / vCPU creation still matches against
> + * the adjusted TSC timeline. The recorded
> + * {cur_tsc_nsec, cur_tsc_write} pair needs no
> + * adjustment: the guest TSC is kept continuous
> + * across the host TSC jump, and that pair lives in
> + * the wall-clock/guest-cycle domain.
> + */
> + raw_spin_lock_irqsave(&kvm->arch.tsc_write_lock, flags);
> kvm->arch.backwards_tsc_observed = true;
> kvm_for_each_vcpu(i, vcpu, kvm) {
> vcpu->arch.tsc_offset_adjustment += delta_cyc;
> @@ -9881,14 +9901,10 @@ int kvm_arch_enable_virtualization_cpu(void)
> kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu);
> }
>
> - /*
> - * We have to disable TSC offset matching.. if you were
> - * booting a VM while issuing an S4 host suspend....
> - * you may have some problem. Solving this issue is
> - * left as an exercise to the reader.
> - */
> - kvm->arch.last_tsc_nsec = 0;
> - kvm->arch.last_tsc_write = 0;
> + kvm->arch.cur_tsc_offset +=
> + kvm_scale_tsc(delta_cyc,
> + kvm->arch.cur_tsc_scaling_ratio);
> + raw_spin_unlock_irqrestore(&kvm->arch.tsc_write_lock, flags);
[Severity: Medium]
Does leaving kvm->arch.cur_tsc_nsec and kvm->arch.cur_tsc_write unadjusted
here cause them to diverge from kvm->arch.cur_tsc_offset by the host sleep
duration after a suspend or hibernate?
In kvm_arch_enable_virtualization_cpu(), delta_cyc = max_tsc - local_tsc only
compensates for the host TSC resetting from max_tsc (recorded at the last
vcpu_put before suspend) to local_tsc. As the earlier comment in
kvm_arch_enable_virtualization_cpu() explains, it does not advance the guest
TSCs by the real time elapsed while the host was suspended. Adjusting
kvm->arch.cur_tsc_offset by the scaled delta_cyc therefore keeps the guest
TSC timeline continuous with its pre-suspend value, excluding the sleep
duration.
However, kvm_synchronize_tsc() obtains ns via kvm_get_time_and_clockread() or
get_kvmclock_base_ns():
arch/x86/kvm/x86.c:get_kvmclock_base_ns() {
return ktime_to_ns(ktime_mono_to_any(ktime_get_raw(), TK_OFFS_BOOT));
}
During resume, timekeeping injects the suspend/hibernate sleep time into
TK_OFFS_BOOT. As a result, elapsed = ns - kvm->arch.cur_tsc_nsec in
kvm_synchronize_tsc() includes the entire host sleep duration, whereas
kvm->arch.cur_tsc_offset and the running guest TSCs do not.
After a suspend or hibernate longer than 1 second where backwards_tsc is
triggered, won't tsc_exp = kvm->arch.cur_tsc_write + nsec_to_cycles(vcpu,
elapsed) be ahead of the guest TSC timeline by the sleep duration, causing
kvm_synchronize_tsc() to mismatch userspace writes that match the post-resume
guest TSC (or falsely match writes that include the sleep duration and snap
their offset back to the unadvanced kvm->arch.cur_tsc_offset), and causing
synchronizing vCPUs (such as data == 0 on vCPU creation) to record
vcpu->arch.last_guest_tsc ahead of the actual guest TSC by the sleep
duration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105154955.2525419-1-dwmw2@infradead.org?part=2
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v11 03/23] KVM: x86: Replace nr_vcpus_matched_tsc count with all_vcpus_matched_tsc bool
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
2026-11-05 15:49 ` [PATCH v11 01/23] KVM: x86: Improve synchronization in kvm_synchronize_tsc() David Woodhouse
2026-11-05 15:49 ` [PATCH v11 02/23] KVM: x86: Kill last_tsc_{nsec,write,offset} fields David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 15:49 ` [PATCH v11 04/23] KVM: x86: Allow KVM master clock mode when TSCs are offset from each other David Woodhouse
` (19 subsequent siblings)
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
Using a count and comparing with kvm->online_vcpus was always racy
because a new vCPU could be created while kvm_track_tsc_matching() was
running and comparing with kvm->online_vcpus. That variable is only
atomic with respect to itself; kvm_arch_vcpu_create() runs before
kvm->online_vcpus is incremented for the new vCPU.
Replace the count with a boolean that is set in kvm_track_tsc_matching()
after comparing the count, and cleared when a new TSC generation starts.
The boolean is consumed by pvclock_update_vm_gtod_copy() under the
tsc_write_lock, which serializes against __kvm_synchronize_tsc().
Keep the count for now as it's still used in the trace event.
Note that the explicit clear of the flag when a new generation starts
is currently overwritten by the unconditional recompute in
kvm_track_tsc_matching() under the same lock; it is preparation for
subsequent patches which consume the previous value of the flag.
Initialize the flag to true at VM creation: a VM whose vCPUs never
reach kvm_track_tsc_matching() — notably with a protected guest TSC
(TDX, SNP Secure TSC), where __kvm_synchronize_tsc() returns early —
would otherwise never be eligible for PVCLOCK_TSC_STABLE_BIT, where
the old read-time computation gave 0 + 1 == 1 for a single-vCPU VM.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/include/asm/kvm_host.h | 1 +
arch/x86/kvm/x86.c | 18 ++++++++++++++----
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index ea48b1949316..1efca01647d2 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1242,6 +1242,7 @@ struct kvm_arch {
u64 cur_tsc_write;
u64 cur_tsc_offset;
u64 cur_tsc_generation;
+ bool all_vcpus_matched_tsc;
int nr_vcpus_matched_tsc;
u32 default_tsc_khz;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 90f9b07ef749..ec8693f4827f 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1125,8 +1125,10 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool new_generation)
* and all vCPUs must have matching TSCs. Note, the count for matching
* vCPUs doesn't include the reference vCPU, hence "+1".
*/
- bool use_master_clock = (ka->nr_vcpus_matched_tsc + 1 ==
- atomic_read(&vcpu->kvm->online_vcpus)) &&
+ ka->all_vcpus_matched_tsc = (ka->nr_vcpus_matched_tsc + 1 ==
+ atomic_read(&vcpu->kvm->online_vcpus));
+
+ bool use_master_clock = ka->all_vcpus_matched_tsc &&
gtod_is_based_on_tsc(gtod->clock.vclock_mode);
/*
@@ -1367,6 +1369,7 @@ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc,
kvm->arch.cur_tsc_write = tsc;
kvm->arch.cur_tsc_offset = offset;
kvm->arch.nr_vcpus_matched_tsc = 0;
+ kvm->arch.all_vcpus_matched_tsc = false;
} else if (vcpu->arch.this_tsc_generation != kvm->arch.cur_tsc_generation) {
kvm->arch.nr_vcpus_matched_tsc++;
}
@@ -1591,8 +1594,7 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
bool host_tsc_clocksource, vcpus_matched;
lockdep_assert_held(&kvm->arch.tsc_write_lock);
- vcpus_matched = (ka->nr_vcpus_matched_tsc + 1 ==
- atomic_read(&kvm->online_vcpus));
+ vcpus_matched = ka->all_vcpus_matched_tsc;
/*
* If the host uses TSC clock, then passthrough TSC as stable
@@ -10007,6 +10009,14 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
ratelimit_set_flags(&kvm->arch.kvmclock_update_rs, RATELIMIT_MSG_ON_RELEASE);
kvm->arch.kvmclock_offset = -get_kvmclock_base_ns();
+ /*
+ * Start with all (zero) vCPUs considered matched, so that a VM whose
+ * vCPUs never reach kvm_track_tsc_matching() — notably when the guest
+ * TSC is protected (TDX, SNP Secure TSC) and __kvm_synchronize_tsc()
+ * returns early — is still eligible for PVCLOCK_TSC_STABLE_BIT.
+ */
+ kvm->arch.all_vcpus_matched_tsc = true;
+
raw_spin_lock_irqsave(&kvm->arch.tsc_write_lock, flags);
pvclock_update_vm_gtod_copy(kvm);
raw_spin_unlock_irqrestore(&kvm->arch.tsc_write_lock, flags);
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v11 04/23] KVM: x86: Allow KVM master clock mode when TSCs are offset from each other
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (2 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 03/23] KVM: x86: Replace nr_vcpus_matched_tsc count with all_vcpus_matched_tsc bool David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 17:27 ` sashiko-bot
2026-11-05 15:49 ` [PATCH v11 05/23] KVM: x86: Factor out kvm_use_master_clock() David Woodhouse
` (18 subsequent siblings)
22 siblings, 1 reply; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
Previously, a guest writing different TSC values on different vCPUs could
force KVM out of master clock mode. With this change, only a frequency
mismatch disables master clock. The only ways for non-master-clock mode
to happen now are archaic hardware without a TSC-based clocksource, a
VMM that sets different TSC frequencies across vCPUs, or a guest using
the legacy MSR_KVM_SYSTEM_TIME (which could be addressed in future by
simply updating tsc_timestamp more frequently rather than falling out of
master clock mode entirely).
Running at a different frequency would lead to a systemic skew between
the clock(s) as observed by different vCPUs due to arithmetic precision
in the scaling. So that should indeed force the clock to be based on the
host's CLOCK_MONOTONIC_RAW instead of being in masterclock mode where it
is defined by the guest TSC.
But vCPUs having different TSC *offsets* is not a problem, because the
KVM clock is a single VM-wide nanosecond timeline; only its expression
in TSC cycles is per-vCPU. Each vCPU's pvclock structure is generated by
translating the shared master clock snapshot into that vCPU's own TSC
domain via kvm_read_l1_tsc(), which applies the vCPU's scaling ratio and
offset to the snapshot's tsc_timestamp. When the guest then computes
system_time + (rdtsc - tsc_timestamp) * rate, its own offset is present
in both rdtsc and tsc_timestamp and cancels out: every vCPU reads the
same VM-wide clock from its own pvclock. VM-scoped consumers of the
master clock (KVM_GET_CLOCK, the wall clock epoch, the Xen runstate
times) operate purely in the nanosecond domain, where the per-vCPU
offset never appears at all.
Only two consumers genuinely depend on the TSC offsets matching, and
both are already guarded by PVCLOCK_TSC_STABLE_BIT:
1. A guest vCPU reading a *sibling* vCPU's pvclock structure with its
own TSC would compute garbage. This is precisely why commit
b48aa97e3820 ("KVM: x86: require matched TSC offsets for master clock")
required matched offsets. But the guest-side guard for it already
exists: when PVCLOCK_TSC_STABLE_BIT is clear, guests fall back to
the global last_value monotonicity clamp for cross-vCPU reads.
2. The Hyper-V TSC page is a single VM-wide {scale, offset} pair which
every guest vCPU applies to its own rdtsc, so it cannot represent
divergent offsets. It is self-guarding: compute_tsc_page_parameters()
refuses to populate the page unless PVCLOCK_TSC_STABLE_BIT is set,
which forces such guests onto the (nanosecond domain, and thus safe)
TIME_REF_COUNT MSR instead.
So: use frequency match for master clock eligibility, and full TSC match
(including offset) only for PVCLOCK_TSC_STABLE_BIT, which tells the
guest it is safe to skip cross-vCPU monotonicity enforcement.
Track frequency matching separately from offset matching using a
dedicated freq generation counter (cur_tsc_freq_generation) that only
bumps on actual frequency changes. Each vCPU is counted exactly once per
freq generation via a per-vCPU this_tsc_freq_generation field, preventing
repeated syncs of the same vCPU from falsely re-enabling master clock.
Note that the generation-based counting has a known limitation: if all
vCPUs are in sync and one changes away and then back again, the other
vCPUs are still at the old generation and won't be counted until they
sync again (which may never happen). This was always the case for the
offset tracking and isn't expected VMM behaviour — although it is the
scenario that the VM-wide KVM_SET_TSC_KHZ ioctl was introduced to handle
cleanly.
While at it, restructure the existing TSC offset generation tracking to
use the same pattern: reset counter to zero on new generation, then
unconditionally count vCPUs that haven't been seen in this generation.
Both counters now use a consistent >= online_vcpus threshold (1-based
counting where the reference vCPU is included in the count).
The divergent-offset behaviour is exercised by pvclock_migration_test,
which runs vCPUs with TSCs offset by ±0.5-1s from each other and
verifies that the master clock survives, that PVCLOCK_TSC_STABLE_BIT is
cleared, and that all vCPUs nevertheless agree on the KVM clock to
within a nanosecond, before and after a simulated live migration.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/include/asm/kvm_host.h | 4 ++
arch/x86/kvm/x86.c | 88 ++++++++++++++++++++++++++-------
2 files changed, 73 insertions(+), 19 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 1efca01647d2..30e89e8fb975 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -887,6 +887,7 @@ struct kvm_vcpu_arch {
u64 this_tsc_nsec;
u64 this_tsc_write;
u64 this_tsc_generation;
+ u64 this_tsc_freq_generation;
bool tsc_catchup;
bool tsc_always_catchup;
s8 virtual_tsc_shift;
@@ -1243,6 +1244,9 @@ struct kvm_arch {
u64 cur_tsc_offset;
u64 cur_tsc_generation;
bool all_vcpus_matched_tsc;
+ bool all_vcpus_matched_freq;
+ int nr_vcpus_matched_freq;
+ u64 cur_tsc_freq_generation;
int nr_vcpus_matched_tsc;
u32 default_tsc_khz;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ec8693f4827f..38fcb1d75661 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1114,30 +1114,63 @@ static inline bool gtod_is_based_on_tsc(int mode)
}
#endif
-static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool new_generation)
+static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool update_mclock)
{
#ifdef CONFIG_X86_64
struct kvm_arch *ka = &vcpu->kvm->arch;
struct pvclock_gtod_data *gtod = &pvclock_gtod_data;
+ bool prev_matched_tsc = ka->all_vcpus_matched_tsc;
/*
- * To use the masterclock, the host clocksource must be based on TSC
- * and all vCPUs must have matching TSCs. Note, the count for matching
- * vCPUs doesn't include the reference vCPU, hence "+1".
+ * Track whether all vCPUs have matching TSC offsets (for
+ * PVCLOCK_TSC_STABLE_BIT) and matching frequencies (for
+ * master clock eligibility).
+ */
+
+ /*
+ * A new vCPU might already have incremented ->online_vcpus
+ * and cause a temporary false negative here. But will then
+ * call kvm_synchronize_tsc() from kvm_arch_vcpu_postcreate()
+ * and finish the job.
+ */
+ int online = atomic_read(&vcpu->kvm->online_vcpus);
+ /*
+ * WRITE_ONCE() pairs with the READ_ONCE() in kvm_guest_time_update(),
+ * which samples the flag locklessly (outside both tsc_write_lock and
+ * its pvclock seqcount read section); the race is benign (a stale
+ * value merely delays the PVCLOCK_TSC_STABLE_BIT broadcast to the
+ * masterclock update which is requested below).
*/
- ka->all_vcpus_matched_tsc = (ka->nr_vcpus_matched_tsc + 1 ==
- atomic_read(&vcpu->kvm->online_vcpus));
+ WRITE_ONCE(ka->all_vcpus_matched_tsc,
+ ka->nr_vcpus_matched_tsc >= online);
- bool use_master_clock = ka->all_vcpus_matched_tsc &&
+ update_mclock |= (prev_matched_tsc != ka->all_vcpus_matched_tsc);
+
+ /*
+ * all_vcpus_matched_freq starts true and is cleared when
+ * __kvm_synchronize_tsc() detects a frequency mismatch.
+ * Re-enable when all vCPUs have synced with matching frequency.
+ * If all offsets also match, that implies frequencies match too.
+ */
+ if (ka->all_vcpus_matched_tsc ||
+ ka->nr_vcpus_matched_freq >= online)
+ ka->all_vcpus_matched_freq = true;
+
+ /*
+ * To use the masterclock, the host clocksource must be based on TSC
+ * and all vCPUs must have matching TSC *frequency*. Different offsets
+ * are fine — each vCPU's pvclock has its own tsc_timestamp that
+ * accounts for its offset.
+ */
+ bool use_master_clock = ka->all_vcpus_matched_freq &&
gtod_is_based_on_tsc(gtod->clock.vclock_mode);
/*
- * Request a masterclock update if the masterclock needs to be toggled
- * on/off, or when starting a new generation and the masterclock is
- * enabled (compute_guest_tsc() requires the masterclock snapshot to be
- * taken _after_ the new generation is created).
+ * Request a masterclock update if needed: toggling master clock,
+ * new generation requiring a fresh snapshot, or a change in
+ * all_vcpus_matched_tsc (to broadcast PVCLOCK_TSC_STABLE_BIT).
*/
- if ((ka->use_master_clock && new_generation) ||
+ if ((ka->use_master_clock && update_mclock) ||
(ka->use_master_clock != use_master_clock))
kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu);
@@ -1339,7 +1372,22 @@ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc,
* Track the TSC frequency, scaling ratio, and offset for the current
* generation. These are used to detect matching TSC writes and to
* compute the guest TSC from the host clock.
+ *
+ * If the frequency changed, master clock mode can no longer be used
+ * since the kvmclock scaling factors differ between vCPUs.
*/
+ if (vcpu->arch.virtual_tsc_khz != kvm->arch.cur_tsc_khz) {
+ kvm->arch.cur_tsc_freq_generation++;
+ kvm->arch.all_vcpus_matched_freq = false;
+ kvm->arch.nr_vcpus_matched_freq = 0;
+ }
+
+ /* Count each vCPU once per freq generation */
+ if (vcpu->arch.this_tsc_freq_generation != kvm->arch.cur_tsc_freq_generation) {
+ vcpu->arch.this_tsc_freq_generation = kvm->arch.cur_tsc_freq_generation;
+ kvm->arch.nr_vcpus_matched_freq++;
+ }
+
kvm->arch.cur_tsc_khz = vcpu->arch.virtual_tsc_khz;
kvm->arch.cur_tsc_scaling_ratio = vcpu->arch.l1_tsc_scaling_ratio;
@@ -1365,17 +1413,18 @@ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc,
* exact software computation in compute_guest_tsc()
*/
kvm->arch.cur_tsc_generation++;
+ WRITE_ONCE(kvm->arch.all_vcpus_matched_tsc, false);
+ kvm->arch.nr_vcpus_matched_tsc = 0;
kvm->arch.cur_tsc_nsec = ns;
kvm->arch.cur_tsc_write = tsc;
kvm->arch.cur_tsc_offset = offset;
- kvm->arch.nr_vcpus_matched_tsc = 0;
- kvm->arch.all_vcpus_matched_tsc = false;
- } else if (vcpu->arch.this_tsc_generation != kvm->arch.cur_tsc_generation) {
+ }
+
+ if (vcpu->arch.this_tsc_generation != kvm->arch.cur_tsc_generation) {
+ vcpu->arch.this_tsc_generation = kvm->arch.cur_tsc_generation;
kvm->arch.nr_vcpus_matched_tsc++;
}
- /* Keep track of which generation this VCPU has synchronized to */
- vcpu->arch.this_tsc_generation = kvm->arch.cur_tsc_generation;
vcpu->arch.this_tsc_nsec = kvm->arch.cur_tsc_nsec;
vcpu->arch.this_tsc_write = kvm->arch.cur_tsc_write;
@@ -1594,7 +1643,7 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
bool host_tsc_clocksource, vcpus_matched;
lockdep_assert_held(&kvm->arch.tsc_write_lock);
- vcpus_matched = ka->all_vcpus_matched_tsc;
+ vcpus_matched = ka->all_vcpus_matched_freq;
/*
* If the host uses TSC clock, then passthrough TSC as stable
@@ -1922,7 +1971,7 @@ int kvm_guest_time_update(struct kvm_vcpu *v)
/* If the host uses TSC clocksource, then it is stable */
hv_clock.flags = 0;
- if (use_master_clock)
+ if (use_master_clock && READ_ONCE(ka->all_vcpus_matched_tsc))
hv_clock.flags |= PVCLOCK_TSC_STABLE_BIT;
if (vcpu->pv_time.active) {
@@ -10008,6 +10057,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
ratelimit_state_init(&kvm->arch.kvmclock_update_rs, HZ, 10);
ratelimit_set_flags(&kvm->arch.kvmclock_update_rs, RATELIMIT_MSG_ON_RELEASE);
kvm->arch.kvmclock_offset = -get_kvmclock_base_ns();
+ kvm->arch.all_vcpus_matched_freq = true;
/*
* Start with all (zero) vCPUs considered matched, so that a VM whose
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v11 04/23] KVM: x86: Allow KVM master clock mode when TSCs are offset from each other
2026-11-05 15:49 ` [PATCH v11 04/23] KVM: x86: Allow KVM master clock mode when TSCs are offset from each other David Woodhouse
@ 2026-11-05 17:27 ` sashiko-bot
0 siblings, 0 replies; 33+ messages in thread
From: sashiko-bot @ 2026-11-05 17:27 UTC (permalink / raw)
To: David Woodhouse, kvm
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] KVM: x86: stale pvclock tsc_timestamp after __kvm_synchronize_tsc()
- [Medium] KVM: x86: missing masterclock update in kvm_track_tsc_matching()
--
commit e48b3906906a2154ee31b39c2d8cc74f2ed71a9f
Author: David Woodhouse <dwmw@amazon.co.uk>
KVM: x86: Allow KVM master clock mode when TSCs are offset from each other
This commit decouples master clock eligibility from TSC offset matching so
that KVM remains in master clock mode as long as all vCPUs share the same TSC
frequency. Per-vCPU TSC offset matching is tracked separately and used only
to gate PVCLOCK_TSC_STABLE_BIT.
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index ec8693f4827fc..38fcb1d756611 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1114,30 +1114,63 @@ static inline bool gtod_is_based_on_tsc(int mode)
> }
> #endif
>
> -static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool new_generation)
> +static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool update_mclock)
> {
> #ifdef CONFIG_X86_64
> struct kvm_arch *ka = &vcpu->kvm->arch;
> struct pvclock_gtod_data *gtod = &pvclock_gtod_data;
> + bool prev_matched_tsc = ka->all_vcpus_matched_tsc;
>
> /*
> - * To use the masterclock, the host clocksource must be based on TSC
> - * and all vCPUs must have matching TSCs. Note, the count for matching
> - * vCPUs doesn't include the reference vCPU, hence "+1".
> + * Track whether all vCPUs have matching TSC offsets (for
> + * PVCLOCK_TSC_STABLE_BIT) and matching frequencies (for
> + * master clock eligibility).
> + */
> +
> + /*
> + * A new vCPU might already have incremented ->online_vcpus
> + * and cause a temporary false negative here. But will then
> + * call kvm_synchronize_tsc() from kvm_arch_vcpu_postcreate()
> + * and finish the job.
> + */
> + int online = atomic_read(&vcpu->kvm->online_vcpus);
> + /*
> + * WRITE_ONCE() pairs with the READ_ONCE() in kvm_guest_time_update(),
> + * which samples the flag locklessly (outside both tsc_write_lock and
> + * its pvclock seqcount read section); the race is benign (a stale
> + * value merely delays the PVCLOCK_TSC_STABLE_BIT broadcast to the
> + * masterclock update which is requested below).
> */
> - ka->all_vcpus_matched_tsc = (ka->nr_vcpus_matched_tsc + 1 ==
> - atomic_read(&vcpu->kvm->online_vcpus));
> + WRITE_ONCE(ka->all_vcpus_matched_tsc,
> + ka->nr_vcpus_matched_tsc >= online);
>
> - bool use_master_clock = ka->all_vcpus_matched_tsc &&
> + update_mclock |= (prev_matched_tsc != ka->all_vcpus_matched_tsc);
> +
> + /*
> + * all_vcpus_matched_freq starts true and is cleared when
> + * __kvm_synchronize_tsc() detects a frequency mismatch.
> + * Re-enable when all vCPUs have synced with matching frequency.
> + * If all offsets also match, that implies frequencies match too.
> + */
> + if (ka->all_vcpus_matched_tsc ||
> + ka->nr_vcpus_matched_freq >= online)
> + ka->all_vcpus_matched_freq = true;
> +
> + /*
> + * To use the masterclock, the host clocksource must be based on TSC
> + * and all vCPUs must have matching TSC *frequency*. Different offsets
> + * are fine — each vCPU's pvclock has its own tsc_timestamp that
> + * accounts for its offset.
> + */
> + bool use_master_clock = ka->all_vcpus_matched_freq &&
> gtod_is_based_on_tsc(gtod->clock.vclock_mode);
>
> /*
> - * Request a masterclock update if the masterclock needs to be toggled
> - * on/off, or when starting a new generation and the masterclock is
> - * enabled (compute_guest_tsc() requires the masterclock snapshot to be
> - * taken _after_ the new generation is created).
> + * Request a masterclock update if needed: toggling master clock,
> + * new generation requiring a fresh snapshot, or a change in
> + * all_vcpus_matched_tsc (to broadcast PVCLOCK_TSC_STABLE_BIT).
> */
> - if ((ka->use_master_clock && new_generation) ||
> + if ((ka->use_master_clock && update_mclock) ||
> (ka->use_master_clock != use_master_clock))
> kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu);
[Severity: Medium]
In arch/x86/kvm/x86.c, when ka->all_vcpus_matched_freq transitions from false
to true in kvm_track_tsc_matching(), should that also set update_mclock?
Suppose a VM with 3 online vCPUs already has ka->use_master_clock set to true
from vCPU creation, and userspace updates the TSC frequency on all vCPUs
before entering KVM_RUN:
1. vCPU 0 and vCPU 1 call __kvm_synchronize_tsc() at the new frequency with
divergent offsets (matched == false). ka->all_vcpus_matched_freq becomes
false and KVM_REQ_MASTERCLOCK_UPDATE is queued on vCPU 0 and vCPU 1, but
ka->use_master_clock remains true until a vCPU enters the guest and
services the request.
2. vCPU 2 then calls __kvm_synchronize_tsc() at the new frequency with an
offset matching vCPU 1 (matched == true). ka->nr_vcpus_matched_freq
reaches online (3), so ka->all_vcpus_matched_freq transitions from false
to true and local use_master_clock is true. However, ka->nr_vcpus_matched_tsc
is 2 (< 3), so ka->all_vcpus_matched_tsc stays false and update_mclock
remains false.
Because ka->use_master_clock is still true and local use_master_clock is also
true, both (ka->use_master_clock && update_mclock) and
(ka->use_master_clock != use_master_clock) evaluate to false. Could vCPU 2
then enter KVM_RUN without KVM_REQ_MASTERCLOCK_UPDATE set and use stale
master_tsc_scaling_ratio, master_tsc_mul, and master_tsc_shift values from the
old frequency?
[ ... ]
> @@ -1365,17 +1413,18 @@ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc,
> * exact software computation in compute_guest_tsc()
> */
> kvm->arch.cur_tsc_generation++;
> + WRITE_ONCE(kvm->arch.all_vcpus_matched_tsc, false);
> + kvm->arch.nr_vcpus_matched_tsc = 0;
> kvm->arch.cur_tsc_nsec = ns;
> kvm->arch.cur_tsc_write = tsc;
> kvm->arch.cur_tsc_offset = offset;
> - kvm->arch.nr_vcpus_matched_tsc = 0;
> - kvm->arch.all_vcpus_matched_tsc = false;
> - } else if (vcpu->arch.this_tsc_generation != kvm->arch.cur_tsc_generation) {
> + }
> +
> + if (vcpu->arch.this_tsc_generation != kvm->arch.cur_tsc_generation) {
> + vcpu->arch.this_tsc_generation = kvm->arch.cur_tsc_generation;
> kvm->arch.nr_vcpus_matched_tsc++;
> }
>
> - /* Keep track of which generation this VCPU has synchronized to */
> - vcpu->arch.this_tsc_generation = kvm->arch.cur_tsc_generation;
> vcpu->arch.this_tsc_nsec = kvm->arch.cur_tsc_nsec;
> vcpu->arch.this_tsc_write = kvm->arch.cur_tsc_write;
>
> kvm_track_tsc_matching(vcpu, !matched);
> }
[Severity: High]
Can __kvm_synchronize_tsc() in arch/x86/kvm/x86.c leave a vCPU's guest
pvclock tsc_timestamp stale when matched is true?
In kvm_guest_time_update(), master clock mode populates each vCPU's
hv_clock.tsc_timestamp using its own l1_tsc_offset:
if (use_master_clock) {
hv_clock.tsc_timestamp = kvm_read_l1_tsc(v, master_tsc);
hv_clock.system_time = master_ns + v->kvm->arch.kvmclock_offset;
}
When __kvm_synchronize_tsc() is called via kvm_synchronize_tsc() or
kvm_arch_tsc_set_attr(), it updates vcpu->arch.l1_tsc_offset through
kvm_vcpu_write_tsc_offset(vcpu, offset) without requesting
KVM_REQ_CLOCK_UPDATE on vcpu, and then calls:
kvm_track_tsc_matching(vcpu, !matched);
With this change, ka->use_master_clock remains true even when vCPUs have
different TSC offsets. If matched is true and ka->all_vcpus_matched_tsc does
not change its boolean value in kvm_track_tsc_matching(), update_mclock stays
false and neither KVM_REQ_MASTERCLOCK_UPDATE nor KVM_REQ_CLOCK_UPDATE is
requested.
For example, this can happen when:
1. A VM has 3 or more online vCPUs with divergent offsets: vCPU 0 sets a new
offset (matched == false), vCPU 1 synchronizes to vCPU 0's offset
(matched == true, nr_vcpus_matched_tsc becomes 2 < 3 so
all_vcpus_matched_tsc remains false), while vCPU 2 stays at a different
offset.
2. A vCPU whose l1_tsc_offset was modified by the guest via
MSR_IA32_TSC_ADJUST or MSR_IA32_TSC (which do not clear
ka->all_vcpus_matched_tsc) is later synchronized back to cur_tsc_offset by
host userspace (matched == true, while all_vcpus_matched_tsc was already
true).
Since kvm_arch_vcpu_load() also skips requesting KVM_REQ_CLOCK_UPDATE when
ka->use_master_clock is true and vcpu->cpu != -1, wouldn't the vCPU re-enter
the guest with the new hardware l1_tsc_offset in rdtsc while its pvclock
struct in guest memory still holds the old tsc_timestamp?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105154955.2525419-1-dwmw2@infradead.org?part=4
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v11 05/23] KVM: x86: Factor out kvm_use_master_clock()
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (3 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 04/23] KVM: x86: Allow KVM master clock mode when TSCs are offset from each other David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 15:49 ` [PATCH v11 06/23] KVM: x86: Avoid gratuitous global clock updates David Woodhouse
` (17 subsequent siblings)
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
Both kvm_track_tsc_matching() and pvclock_update_vm_gtod_copy() make a
decision about whether the KVM clock should be in master clock mode.
They used *different* criteria for the decision though. This isn't
really a problem; it only has the potential to cause unnecessary
invocations of KVM_REQ_MASTERCLOCK_UPDATE if the masterclock was
disabled due to TSC going backwards, or the guest using the old MSR.
But it isn't pretty.
Factor the decision out to a single function. And document the
historical reason why it's disabled for guests that use the old
MSR_KVM_SYSTEM_TIME.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
---
arch/x86/kvm/x86.c | 40 ++++++++++++++++++++++++++++++----------
1 file changed, 30 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 38fcb1d75661..4c3fce29e2af 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1112,11 +1112,30 @@ static inline bool gtod_is_based_on_tsc(int mode)
{
return mode == VDSO_CLOCKMODE_TSC || mode == VDSO_CLOCKMODE_HVCLOCK;
}
-#endif
+
+static bool kvm_use_master_clock(struct kvm *kvm)
+{
+ struct kvm_arch *ka = &kvm->arch;
+
+ /*
+ * The 'old kvmclock' check is a workaround (from 2015) for a
+ * SUSE 2.6.16 kernel that didn't boot if the system_time in
+ * its kvmclock was too far behind the current time. So the
+ * mode of just setting the reference point and allowing time
+ * to proceed linearly from there makes it fail to boot.
+ * Despite that being kind of the *point* of the way the clock
+ * is exposed to the guest. By coincidence, the offending
+ * kernels used the old MSR_KVM_SYSTEM_TIME, which was moved
+ * only because it resided in the wrong number range. So the
+ * workaround is activated for *all* guests using the old MSR.
+ */
+ return ka->all_vcpus_matched_freq &&
+ !ka->backwards_tsc_observed &&
+ !ka->boot_vcpu_runs_old_kvmclock;
+}
static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool update_mclock)
{
-#ifdef CONFIG_X86_64
struct kvm_arch *ka = &vcpu->kvm->arch;
struct pvclock_gtod_data *gtod = &pvclock_gtod_data;
bool prev_matched_tsc = ka->all_vcpus_matched_tsc;
@@ -1162,7 +1181,7 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool update_mclock)
* are fine — each vCPU's pvclock has its own tsc_timestamp that
* accounts for its offset.
*/
- bool use_master_clock = ka->all_vcpus_matched_freq &&
+ bool use_master_clock = kvm_use_master_clock(vcpu->kvm) &&
gtod_is_based_on_tsc(gtod->clock.vclock_mode);
/*
@@ -1177,8 +1196,11 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool update_mclock)
trace_kvm_track_tsc(vcpu->vcpu_id, ka->nr_vcpus_matched_tsc,
atomic_read(&vcpu->kvm->online_vcpus),
ka->use_master_clock, gtod->clock.vclock_mode);
-#endif
}
+#else
+static inline void kvm_track_tsc_matching(struct kvm_vcpu *vcpu,
+ bool update_mclock) {}
+#endif
/*
* Multiply tsc by a fixed point number represented by ratio.
@@ -1640,10 +1662,9 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
#ifdef CONFIG_X86_64
struct kvm_arch *ka = &kvm->arch;
int vclock_mode;
- bool host_tsc_clocksource, vcpus_matched;
+ bool host_tsc_clocksource;
lockdep_assert_held(&kvm->arch.tsc_write_lock);
- vcpus_matched = ka->all_vcpus_matched_freq;
/*
* If the host uses TSC clock, then passthrough TSC as stable
@@ -1653,9 +1674,8 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
&ka->master_kernel_ns,
&ka->master_cycle_now);
- ka->use_master_clock = host_tsc_clocksource && vcpus_matched
- && !ka->backwards_tsc_observed
- && !ka->boot_vcpu_runs_old_kvmclock;
+ ka->use_master_clock = host_tsc_clocksource &&
+ kvm_use_master_clock(kvm);
if (ka->use_master_clock) {
u64 tsc_hz;
@@ -1683,7 +1703,7 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
vclock_mode = pvclock_gtod_data.clock.vclock_mode;
trace_kvm_update_master_clock(ka->use_master_clock, vclock_mode,
- vcpus_matched);
+ ka->all_vcpus_matched_freq);
#endif
}
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v11 06/23] KVM: x86: Avoid gratuitous global clock updates
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (4 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 05/23] KVM: x86: Factor out kvm_use_master_clock() David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 15:49 ` [PATCH v11 07/23] KVM: x86: Avoid redundant masterclock updates from multiple vCPUs David Woodhouse
` (16 subsequent siblings)
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
Eliminate two sources of unnecessary KVM_REQ_GLOBAL_CLOCK_UPDATE:
1. kvm_write_system_time(): The global clock update was a workaround for
ever-drifting clocks based on the host's CLOCK_MONOTONIC subject to
NTP skew. Now that the KVM clock uses CLOCK_MONOTONIC_RAW, the clock
does not drift with NTP corrections and there is no need to
synchronize all vCPUs on boot or resume. Use KVM_REQ_CLOCK_UPDATE on
the vCPU itself, and only when the clock is being enabled, not
disabled.
2. kvm_arch_vcpu_load(): In master clock mode, migration between pCPUs
does not require any clock update since the master clock reference is
shared. Only request a local KVM_REQ_CLOCK_UPDATE for the vCPU's
first-ever load (vcpu->cpu == -1) to generate initial pvclock params.
In non-master-clock mode, keep the global update to synchronize all
vCPUs.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/kvm/msrs.c | 7 ++++---
arch/x86/kvm/x86.c | 4 +++-
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c
index e91650af44c2..a2dffa1c706f 100644
--- a/arch/x86/kvm/msrs.c
+++ b/arch/x86/kvm/msrs.c
@@ -1285,14 +1285,15 @@ static void kvm_write_system_time(struct kvm_vcpu *vcpu, gpa_t system_time,
}
vcpu->arch.time = system_time;
- kvm_make_request(KVM_REQ_GLOBAL_CLOCK_UPDATE, vcpu);
/* we verify if the enable bit is set... */
- if (system_time & 1)
+ if (system_time & 1) {
kvm_gpc_activate(&vcpu->arch.pv_time, system_time & ~1ULL,
sizeof(struct pvclock_vcpu_time_info));
- else
+ kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
+ } else {
kvm_gpc_deactivate(&vcpu->arch.pv_time);
+ }
return;
}
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 4c3fce29e2af..e3618d82c099 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2702,11 +2702,13 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
* On a host with synchronized TSC, there is no need to update
* kvmclock on vcpu->cpu migration
*/
- if (!vcpu->kvm->arch.use_master_clock || vcpu->cpu == -1) {
+ if (!vcpu->kvm->arch.use_master_clock) {
if (__ratelimit(&vcpu->kvm->arch.kvmclock_update_rs))
kvm_make_request(KVM_REQ_GLOBAL_CLOCK_UPDATE, vcpu);
else
kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
+ } else if (vcpu->cpu == -1) {
+ kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
}
if (vcpu->cpu != cpu)
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v11 07/23] KVM: x86: Avoid redundant masterclock updates from multiple vCPUs
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (5 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 06/23] KVM: x86: Avoid gratuitous global clock updates David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 18:00 ` sashiko-bot
2026-11-05 15:49 ` [PATCH v11 08/23] KVM: x86: Re-synchronize TSC after KVM_SET_TSC_KHZ David Woodhouse
` (15 subsequent siblings)
22 siblings, 1 reply; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
When a masterclock update is triggered (e.g. by the clocksource change
notifier), KVM_REQ_MASTERCLOCK_UPDATE is set on all vCPUs. Without this
fix, each vCPU independently processes the request and redundantly
re-executes the entire pvclock_update_vm_gtod_copy() sequence, serialized
only by tsc_write_lock. Each redundant re-snapshot of the master clock
reference point introduces potential clock drift.
Fix this by having __kvm_start_pvclock_update() check, after acquiring
the lock, whether the requesting vCPU's KVM_REQ_MASTERCLOCK_UPDATE is
still set. If another vCPU already did the update and cleared it, bail
out. Otherwise, clear the request on all other vCPUs before proceeding.
The caller in vcpu_enter_guest() now uses kvm_test_request() (non-clearing)
since the clearing is done inside __kvm_start_pvclock_update() under the
lock.
kvm_end_pvclock_update() now broadcasts KVM_REQ_CLOCK_UPDATE and clears
KVM_REQ_MCLOCK_INPROGRESS while still inside the interrupts-off lock
section with the seqcount held open. That ordering is load-bearing for
the bail-out path: a vCPU whose request was consumed by another updater
must be guaranteed to observe either the open seqcount or its pending
KVM_REQ_CLOCK_UPDATE before it can enter the guest.
Since the update now consumes pending KVM_REQ_MASTERCLOCK_UPDATE
requests, the Hyper-V reenlightenment notifier must invalidate the
Hyper-V TSC page itself; previously a pending request survived the
notifier and refreshed the page via kvm_update_masterclock() later.
Suggested-by: Dongli Zhang <dongli.zhang@oracle.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Tested-by: Dongli Zhang <dongli.zhang@oracle.com>
---
arch/x86/kvm/msrs.c | 11 ++++++--
arch/x86/kvm/x86.c | 67 +++++++++++++++++++++++++++++++++++----------
2 files changed, 61 insertions(+), 17 deletions(-)
diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c
index a2dffa1c706f..26eb30f10c43 100644
--- a/arch/x86/kvm/msrs.c
+++ b/arch/x86/kvm/msrs.c
@@ -1278,10 +1278,15 @@ static void kvm_write_system_time(struct kvm_vcpu *vcpu, gpa_t system_time,
struct kvm_arch *ka = &vcpu->kvm->arch;
if (vcpu->vcpu_id == 0 && !host_initiated) {
- if (ka->boot_vcpu_runs_old_kvmclock != old_msr)
+ /*
+ * Store the flag before requesting the masterclock update:
+ * the update may now be performed by another vCPU (which
+ * consumes this request), and it must observe the new value.
+ */
+ if (ka->boot_vcpu_runs_old_kvmclock != old_msr) {
+ ka->boot_vcpu_runs_old_kvmclock = old_msr;
kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu);
-
- ka->boot_vcpu_runs_old_kvmclock = old_msr;
+ }
}
vcpu->arch.time = system_time;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e3618d82c099..77bd3e4bfdcd 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1712,10 +1712,39 @@ static void kvm_make_mclock_inprogress_request(struct kvm *kvm)
kvm_make_all_cpus_request(kvm, KVM_REQ_MCLOCK_INPROGRESS);
}
-static void __kvm_start_pvclock_update(struct kvm *kvm)
+static void kvm_clear_mclock_inprogress_request(struct kvm *kvm)
{
+ struct kvm_vcpu *vcpu;
+ unsigned long i;
+
+ kvm_for_each_vcpu(i, vcpu, kvm)
+ kvm_clear_request(KVM_REQ_MCLOCK_INPROGRESS, vcpu);
+}
+
+static bool __kvm_start_pvclock_update(struct kvm *kvm, struct kvm_vcpu *requesting_vcpu)
+{
+ struct kvm_vcpu *vcpu;
+ unsigned long i;
+
raw_spin_lock_irq(&kvm->arch.tsc_write_lock);
+
+ /*
+ * If another vCPU already did the update while we were waiting
+ * for the lock, our request will have been cleared. Bail out.
+ */
+ if (requesting_vcpu &&
+ !kvm_test_request(KVM_REQ_MASTERCLOCK_UPDATE, requesting_vcpu)) {
+ kvm_clear_mclock_inprogress_request(kvm);
+ raw_spin_unlock_irq(&kvm->arch.tsc_write_lock);
+ return false;
+ }
+
+ /* The update is VM-wide; prevent other vCPUs from redoing it. */
+ kvm_for_each_vcpu(i, vcpu, kvm)
+ kvm_clear_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu);
+
write_seqcount_begin(&kvm->arch.pvclock_sc);
+ return true;
}
static void kvm_start_pvclock_update(struct kvm *kvm)
@@ -1723,7 +1752,7 @@ static void kvm_start_pvclock_update(struct kvm *kvm)
kvm_make_mclock_inprogress_request(kvm);
/* no guest entries from this point */
- __kvm_start_pvclock_update(kvm);
+ __kvm_start_pvclock_update(kvm, NULL);
}
static void kvm_end_pvclock_update(struct kvm *kvm)
@@ -1732,22 +1761,25 @@ static void kvm_end_pvclock_update(struct kvm *kvm)
struct kvm_vcpu *vcpu;
unsigned long i;
- write_seqcount_end(&ka->pvclock_sc);
- raw_spin_unlock_irq(&ka->tsc_write_lock);
kvm_for_each_vcpu(i, vcpu, kvm)
kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
/* guest entries allowed */
- kvm_for_each_vcpu(i, vcpu, kvm)
- kvm_clear_request(KVM_REQ_MCLOCK_INPROGRESS, vcpu);
+ kvm_clear_mclock_inprogress_request(kvm);
+
+ write_seqcount_end(&ka->pvclock_sc);
+ raw_spin_unlock_irq(&ka->tsc_write_lock);
}
-static void kvm_update_masterclock(struct kvm *kvm)
+static void kvm_update_masterclock(struct kvm *kvm, struct kvm_vcpu *vcpu)
{
kvm_hv_request_tsc_page_update(kvm);
- kvm_start_pvclock_update(kvm);
- pvclock_update_vm_gtod_copy(kvm);
- kvm_end_pvclock_update(kvm);
+ kvm_make_mclock_inprogress_request(kvm);
+
+ if (__kvm_start_pvclock_update(kvm, vcpu)) {
+ pvclock_update_vm_gtod_copy(kvm);
+ kvm_end_pvclock_update(kvm);
+ }
}
/*
@@ -6848,7 +6880,14 @@ static void kvm_hyperv_tsc_notifier(void)
kvm_caps.max_guest_tsc_khz = tsc_khz;
list_for_each_entry(kvm, &vm_list, vm_list) {
- __kvm_start_pvclock_update(kvm);
+ /*
+ * Invalidate the Hyper-V TSC page explicitly: the update
+ * below consumes any pending KVM_REQ_MASTERCLOCK_UPDATE,
+ * which would otherwise have refreshed the page from
+ * kvm_update_masterclock().
+ */
+ kvm_hv_request_tsc_page_update(kvm);
+ __kvm_start_pvclock_update(kvm, NULL);
pvclock_update_vm_gtod_copy(kvm);
kvm_end_pvclock_update(kvm);
}
@@ -8254,8 +8293,8 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
kvm_mmu_free_obsolete_roots(vcpu);
if (kvm_check_request(KVM_REQ_MIGRATE_TIMER, vcpu))
__kvm_migrate_timers(vcpu);
- if (kvm_check_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu))
- kvm_update_masterclock(vcpu->kvm);
+ if (kvm_test_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu))
+ kvm_update_masterclock(vcpu->kvm, vcpu);
if (kvm_check_request(KVM_REQ_GLOBAL_CLOCK_UPDATE, vcpu))
kvm_gen_kvmclock_update(vcpu);
if (kvm_check_request(KVM_REQ_CLOCK_UPDATE, vcpu)) {
@@ -9628,7 +9667,7 @@ void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
vcpu_load(vcpu);
kvm_synchronize_tsc(vcpu, NULL);
if (kvm_check_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu))
- kvm_update_masterclock(vcpu->kvm);
+ kvm_update_masterclock(vcpu->kvm, NULL);
vcpu_put(vcpu);
/* poll control enabled by default */
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v11 07/23] KVM: x86: Avoid redundant masterclock updates from multiple vCPUs
2026-11-05 15:49 ` [PATCH v11 07/23] KVM: x86: Avoid redundant masterclock updates from multiple vCPUs David Woodhouse
@ 2026-11-05 18:00 ` sashiko-bot
0 siblings, 0 replies; 33+ messages in thread
From: sashiko-bot @ 2026-11-05 18:00 UTC (permalink / raw)
To: David Woodhouse, kvm
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] KVM: x86: race in kvm_update_masterclock() on MCLOCK_INPROGRESS and TSC page
--
commit 568cc2c30a5c5633833d9fd527d1659f817b9d25
Author: David Woodhouse <dwmw@amazon.co.uk>
KVM: x86: Avoid redundant masterclock updates from multiple vCPUs
This commit avoids redundant masterclock updates when multiple vCPUs process
KVM_REQ_MASTERCLOCK_UPDATE by checking under tsc_write_lock whether the
requesting vCPU's request is still pending and clearing the request across
all vCPUs once a single updater proceeds.
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index e3618d82c099c..77bd3e4bfdcd7 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1712,10 +1712,39 @@ static void kvm_make_mclock_inprogress_request(struct kvm *kvm)
> kvm_make_all_cpus_request(kvm, KVM_REQ_MCLOCK_INPROGRESS);
> }
>
> -static void __kvm_start_pvclock_update(struct kvm *kvm)
> +static void kvm_clear_mclock_inprogress_request(struct kvm *kvm)
> {
> + struct kvm_vcpu *vcpu;
> + unsigned long i;
> +
> + kvm_for_each_vcpu(i, vcpu, kvm)
> + kvm_clear_request(KVM_REQ_MCLOCK_INPROGRESS, vcpu);
> +}
> +
> +static bool __kvm_start_pvclock_update(struct kvm *kvm, struct kvm_vcpu *requesting_vcpu)
> +{
> + struct kvm_vcpu *vcpu;
> + unsigned long i;
> +
> raw_spin_lock_irq(&kvm->arch.tsc_write_lock);
> +
> + /*
> + * If another vCPU already did the update while we were waiting
> + * for the lock, our request will have been cleared. Bail out.
> + */
> + if (requesting_vcpu &&
> + !kvm_test_request(KVM_REQ_MASTERCLOCK_UPDATE, requesting_vcpu)) {
> + kvm_clear_mclock_inprogress_request(kvm);
> + raw_spin_unlock_irq(&kvm->arch.tsc_write_lock);
> + return false;
> + }
> +
> + /* The update is VM-wide; prevent other vCPUs from redoing it. */
> + kvm_for_each_vcpu(i, vcpu, kvm)
> + kvm_clear_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu);
> +
> write_seqcount_begin(&kvm->arch.pvclock_sc);
> + return true;
> }
>
> static void kvm_start_pvclock_update(struct kvm *kvm)
> @@ -1723,7 +1752,7 @@ static void kvm_start_pvclock_update(struct kvm *kvm)
> kvm_make_mclock_inprogress_request(kvm);
>
> /* no guest entries from this point */
> - __kvm_start_pvclock_update(kvm);
> + __kvm_start_pvclock_update(kvm, NULL);
> }
>
> static void kvm_end_pvclock_update(struct kvm *kvm)
> @@ -1732,22 +1761,25 @@ static void kvm_end_pvclock_update(struct kvm *kvm)
> struct kvm_vcpu *vcpu;
> unsigned long i;
>
> - write_seqcount_end(&ka->pvclock_sc);
> - raw_spin_unlock_irq(&ka->tsc_write_lock);
> kvm_for_each_vcpu(i, vcpu, kvm)
> kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
>
> /* guest entries allowed */
> - kvm_for_each_vcpu(i, vcpu, kvm)
> - kvm_clear_request(KVM_REQ_MCLOCK_INPROGRESS, vcpu);
> + kvm_clear_mclock_inprogress_request(kvm);
> +
> + write_seqcount_end(&ka->pvclock_sc);
> + raw_spin_unlock_irq(&ka->tsc_write_lock);
> }
>
> -static void kvm_update_masterclock(struct kvm *kvm)
> +static void kvm_update_masterclock(struct kvm *kvm, struct kvm_vcpu *vcpu)
> {
> kvm_hv_request_tsc_page_update(kvm);
> - kvm_start_pvclock_update(kvm);
> - pvclock_update_vm_gtod_copy(kvm);
> - kvm_end_pvclock_update(kvm);
> + kvm_make_mclock_inprogress_request(kvm);
> +
> + if (__kvm_start_pvclock_update(kvm, vcpu)) {
> + pvclock_update_vm_gtod_copy(kvm);
> + kvm_end_pvclock_update(kvm);
> + }
> }
[Severity: High]
Can calling kvm_hv_request_tsc_page_update() and
kvm_make_mclock_inprogress_request() in kvm_update_masterclock() before
checking whether KVM_REQ_MASTERCLOCK_UPDATE is still pending cause races on
KVM_REQ_MCLOCK_INPROGRESS and hv->hv_tsc_page_status?
In vcpu_enter_guest(), KVM_REQ_MASTERCLOCK_UPDATE is checked with the
non-clearing kvm_test_request() before calling kvm_update_masterclock().
When the first vCPU enters kvm_update_masterclock() and calls
kvm_make_mclock_inprogress_request(kvm), it kicks all other running vCPUs out
of guest mode before acquiring kvm->arch.tsc_write_lock and clearing
KVM_REQ_MASTERCLOCK_UPDATE. Those kicked vCPUs re-enter vcpu_enter_guest(),
still observe KVM_REQ_MASTERCLOCK_UPDATE set, and also call
kvm_update_masterclock(), broadcasting additional rounds of VM-wide
KVM_REQ_MCLOCK_INPROGRESS kicks before bailing out in
__kvm_start_pvclock_update().
When a losing vCPU (vcpu1) acquires tsc_write_lock in
__kvm_start_pvclock_update() after the winning vCPU (vcpu0) has finished,
!kvm_test_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu1) is true and the bail-out
path unconditionally clears KVM_REQ_MCLOCK_INPROGRESS on all vCPUs:
arch/x86/kvm/x86.c:__kvm_start_pvclock_update() {
if (requesting_vcpu &&
!kvm_test_request(KVM_REQ_MASTERCLOCK_UPDATE, requesting_vcpu)) {
kvm_clear_mclock_inprogress_request(kvm);
raw_spin_unlock_irq(&kvm->arch.tsc_write_lock);
return false;
}
}
If another updater (such as kvm_vm_ioctl_set_clock() via
kvm_start_pvclock_update(), kvm_hyperv_tsc_notifier(),
kvm_arch_vcpu_postcreate(), or another vCPU handling a per-vCPU
KVM_REQ_MASTERCLOCK_UPDATE from kvm_synchronize_tsc(),
kvm_write_system_time(), or kvm_hv_set_msr_pw()) has already called
kvm_make_mclock_inprogress_request(kvm) and is waiting on tsc_write_lock (or
running hyperv_stop_tsc_emulation()), vcpu1's bail-out clears
KVM_REQ_MCLOCK_INPROGRESS across all vCPUs in the VM (and similarly
kvm_end_pvclock_update() clears KVM_REQ_MCLOCK_INPROGRESS even if another
caller has already set it while spinning on tsc_write_lock). Other vCPUs can
then enter IN_GUEST_MODE while the second update is in progress. Because
kvm_end_pvclock_update() sets KVM_REQ_CLOCK_UPDATE with kvm_make_request()
without kicking vCPUs, vCPUs that entered guest mode early will not be kicked
and can run with stale pvclock state.
Similarly, because kvm_hv_request_tsc_page_update(kvm) runs before
__kvm_start_pvclock_update() checks KVM_REQ_MASTERCLOCK_UPDATE, two races on
hv->hv_tsc_page_status can occur:
1. If vcpu0 and vcpu1 both call kvm_hv_request_tsc_page_update(kvm), vcpu0
completes the update and runs kvm_guest_time_update() ->
kvm_hv_setup_tsc_page() (setting hv->hv_tsc_page_status = HV_TSC_PAGE_SET),
and a new KVM_REQ_MASTERCLOCK_UPDATE is raised before vcpu1 acquires
tsc_write_lock, vcpu1 will see KVM_REQ_MASTERCLOCK_UPDATE set and perform the
second masterclock update without kvm_hv_request_tsc_page_update(kvm) being
called for it. In kvm_hv_setup_tsc_page(), HV_TSC_PAGE_SET causes an early
return, leaving the Hyper-V TSC page stale.
2. If no second update occurs, a lagging vcpu1 that runs
kvm_hv_request_tsc_page_update(kvm) after vcpu0 has already completed
kvm_hv_setup_tsc_page() resets hv_tsc_page_status from HV_TSC_PAGE_SET back
to HV_TSC_PAGE_HOST_CHANGED, bails out in __kvm_start_pvclock_update(), and
then rewrites tsc_sequence and the shared Hyper-V TSC page in
kvm_hv_setup_tsc_page() while other vCPUs are already running in guest mode.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105154955.2525419-1-dwmw2@infradead.org?part=7
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v11 08/23] KVM: x86: Re-synchronize TSC after KVM_SET_TSC_KHZ
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (6 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 07/23] KVM: x86: Avoid redundant masterclock updates from multiple vCPUs David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 18:22 ` sashiko-bot
2026-11-05 15:49 ` [PATCH v11 09/23] KVM: x86: Cache host vclock_mode for masterclock eligibility checks David Woodhouse
` (14 subsequent siblings)
22 siblings, 1 reply; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
KVM_SET_TSC_KHZ changes the vCPU's TSC scaling ratio but does not
update the VM-wide cur_tsc_scaling_ratio used by get_kvmclock().
This causes get_kvmclock() to use a stale (default 1:1) ratio when
computing the KVM clock, leading to drift between the host-side
kvmclock and what the guest observes.
Fix this by calling kvm_synchronize_tsc() after changing the TSC
frequency. This:
- Updates cur_tsc_scaling_ratio (consumed by pvclock_update_vm_gtod_copy)
- Ensures the TSC value is continuous across the frequency change
- Triggers kvm_track_tsc_matching() for proper masterclock handling
- Establishes the new TSC generation for subsequent vCPUs to match
Since kvm_synchronize_tsc() previously inferred "userspace wrote the
TSC" from being given a non-NULL value, and this new call is a purely
kernel-internal resynchronization (including from vCPU creation via
the default frequency), make that an explicit 'user_initiated'
parameter instead. Otherwise the kernel's own call would set
kvm->arch.user_set_tsc and incorrectly enable the 1-second slop
heuristic before userspace has ever written a TSC value, breaking
the restore of a guest with less than one second of runtime.
Only preserve the TSC value across the change for a vCPU which has
actually run. For one which has not, synchronize as for a zero write
instead, joining the current generation. At vCPU creation (which comes
through here with the default frequency) the value read happens to be
zero anyway, because the scaling ratio has not yet been initialized;
make that explicit rather than an accident. For an explicit
KVM_SET_TSC_KHZ on a never-run vCPU, the nonzero value could never
match — userspace has not written a TSC, so the matching window is not
armed — and each such call would open a new TSC generation, orphaning
the matched state of the sibling vCPUs and denying
PVCLOCK_TSC_STABLE_BIT to a multi-vCPU guest whose VMM never writes
the TSCs explicitly. If userspace has already written a TSC, preserve
the value even for a never-run vCPU — a zero write would discard it —
and let the user-write matching window do its usual job.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/kvm/msrs.c | 2 +-
arch/x86/kvm/x86.c | 38 +++++++++++++++++++++++++++++++++-----
arch/x86/kvm/x86.h | 2 +-
3 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/msrs.c b/arch/x86/kvm/msrs.c
index 26eb30f10c43..d07831b5dfb8 100644
--- a/arch/x86/kvm/msrs.c
+++ b/arch/x86/kvm/msrs.c
@@ -1645,7 +1645,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
break;
case MSR_IA32_TSC:
if (msr_info->host_initiated) {
- kvm_synchronize_tsc(vcpu, &data);
+ kvm_synchronize_tsc(vcpu, &data, true);
} else if (!vcpu->arch.guest_tsc_protected) {
u64 adj = kvm_compute_l1_tsc_offset(vcpu, rdtsc(), data) -
vcpu->arch.l1_tsc_offset;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 77bd3e4bfdcd..f551056d7274 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1064,6 +1064,7 @@ static int kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz)
{
u32 thresh_lo, thresh_hi;
int use_scaling = 0;
+ u64 tsc;
/* tsc_khz can be zero if TSC calibration fails */
if (user_tsc_khz == 0) {
@@ -1091,7 +1092,34 @@ static int kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz)
user_tsc_khz, thresh_lo, thresh_hi);
use_scaling = 1;
}
- return set_tsc_khz(vcpu, user_tsc_khz, use_scaling);
+ /*
+ * Read the guest TSC before changing the ratio, so we can
+ * re-synchronize to preserve continuity across the change.
+ */
+ tsc = kvm_read_l1_tsc(vcpu, rdtsc());
+
+ if (set_tsc_khz(vcpu, user_tsc_khz, use_scaling))
+ return -1;
+
+ /*
+ * Preserving continuity only makes sense for a vCPU which has
+ * actually run; for one which has not, synchronize as for a zero
+ * write, joining the current generation. This makes vCPU creation
+ * (which comes through here with the default frequency) join the
+ * generation *explicitly*, rather than by the accident that the
+ * scaling ratio is still zero at this point so the TSC read above
+ * is zero anyway — and it stops an explicit KVM_SET_TSC_KHZ on a
+ * never-run vCPU, whose nonzero TSC value could never match, from
+ * opening a new generation and orphaning the matched state of its
+ * siblings. If userspace has already written a TSC, preserve the
+ * value even for a never-run vCPU — a zero write would discard it —
+ * and let the user-write matching window do its usual job.
+ */
+ if (vcpu->arch.last_vmentry_cpu != -1 || vcpu->kvm->arch.user_set_tsc)
+ kvm_synchronize_tsc(vcpu, &tsc, false);
+ else
+ kvm_synchronize_tsc(vcpu, NULL, false);
+ return 0;
}
static u64 compute_guest_tsc(struct kvm_vcpu *vcpu, s64 kernel_ns)
@@ -1453,9 +1481,9 @@ static void __kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 offset, u64 tsc,
kvm_track_tsc_matching(vcpu, !matched);
}
-void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value)
+void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *value, bool user_initiated)
{
- u64 data = user_value ? *user_value : 0;
+ u64 data = value ? *value : 0;
struct kvm *kvm = vcpu->kvm;
u64 offset, host_tsc, elapsed;
s64 ns;
@@ -1531,7 +1559,7 @@ void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value)
matched = true;
}
- __kvm_synchronize_tsc(vcpu, offset, data, ns, matched, !!user_value);
+ __kvm_synchronize_tsc(vcpu, offset, data, ns, matched, user_initiated);
raw_spin_unlock_irqrestore(&kvm->arch.tsc_write_lock, flags);
}
@@ -9665,7 +9693,7 @@ void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
if (mutex_lock_killable(&vcpu->mutex))
return;
vcpu_load(vcpu);
- kvm_synchronize_tsc(vcpu, NULL);
+ kvm_synchronize_tsc(vcpu, NULL, false);
if (kvm_check_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu))
kvm_update_masterclock(vcpu->kvm, NULL);
vcpu_put(vcpu);
diff --git a/arch/x86/kvm/x86.h b/arch/x86/kvm/x86.h
index 436e2fb1396c..de4c86ea5a7d 100644
--- a/arch/x86/kvm/x86.h
+++ b/arch/x86/kvm/x86.h
@@ -330,7 +330,7 @@ uint64_t kvm_get_wall_clock_epoch(struct kvm *kvm);
bool kvm_get_monotonic_and_clockread(s64 *kernel_ns, u64 *tsc_timestamp);
int kvm_guest_time_update(struct kvm_vcpu *v);
-void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *user_value);
+void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *value, bool user_initiated);
u64 kvm_scale_tsc(u64 tsc, u64 ratio);
u64 kvm_read_l1_tsc(struct kvm_vcpu *vcpu, u64 host_tsc);
u64 kvm_calc_nested_tsc_offset(u64 l1_offset, u64 l2_offset, u64 l2_multiplier);
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v11 08/23] KVM: x86: Re-synchronize TSC after KVM_SET_TSC_KHZ
2026-11-05 15:49 ` [PATCH v11 08/23] KVM: x86: Re-synchronize TSC after KVM_SET_TSC_KHZ David Woodhouse
@ 2026-11-05 18:22 ` sashiko-bot
0 siblings, 0 replies; 33+ messages in thread
From: sashiko-bot @ 2026-11-05 18:22 UTC (permalink / raw)
To: David Woodhouse, kvm
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] KVM: x86: premature kvm_synchronize_tsc() in kvm_arch_vcpu_create()
- [High] KVM: x86: VM-wide user_set_tsc check in kvm_set_tsc_khz() breaks sync
- [Medium] KVM: x86: stale masterclock scaling state after kvm_set_tsc_khz()
- [Medium] KVM: x86: unmatched TSC generations in kvm_set_tsc_khz() after run
--
commit 485fbef9a92020d117515ff0401050c42d986ac4
Author: David Woodhouse <dwmw@amazon.co.uk>
KVM: x86: Re-synchronize TSC after KVM_SET_TSC_KHZ
This commit updates kvm_set_tsc_khz() to invoke kvm_synchronize_tsc() after
changing a vCPU's TSC frequency so that cur_tsc_scaling_ratio and TSC
generation tracking are updated. It also adds an explicit user_initiated
parameter to kvm_synchronize_tsc() to distinguish host userspace MSR_IA32_TSC
writes from internal frequency resynchronizations.
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 77bd3e4bfdcd7..f551056d72746 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1064,6 +1064,7 @@ static int kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz)
> {
> u32 thresh_lo, thresh_hi;
> int use_scaling = 0;
> + u64 tsc;
>
> /* tsc_khz can be zero if TSC calibration fails */
> if (user_tsc_khz == 0) {
> @@ -1091,7 +1092,34 @@ static int kvm_set_tsc_khz(struct kvm_vcpu *vcpu, u32 user_tsc_khz)
> user_tsc_khz, thresh_lo, thresh_hi);
> use_scaling = 1;
> }
> - return set_tsc_khz(vcpu, user_tsc_khz, use_scaling);
> + /*
> + * Read the guest TSC before changing the ratio, so we can
> + * re-synchronize to preserve continuity across the change.
> + */
> + tsc = kvm_read_l1_tsc(vcpu, rdtsc());
> +
> + if (set_tsc_khz(vcpu, user_tsc_khz, use_scaling))
> + return -1;
> +
> + /*
> + * Preserving continuity only makes sense for a vCPU which has
> + * actually run; for one which has not, synchronize as for a zero
> + * write, joining the current generation. This makes vCPU creation
> + * (which comes through here with the default frequency) join the
> + * generation *explicitly*, rather than by the accident that the
> + * scaling ratio is still zero at this point so the TSC read above
> + * is zero anyway — and it stops an explicit KVM_SET_TSC_KHZ on a
> + * never-run vCPU, whose nonzero TSC value could never match, from
> + * opening a new generation and orphaning the matched state of its
> + * siblings. If userspace has already written a TSC, preserve the
> + * value even for a never-run vCPU — a zero write would discard it —
> + * and let the user-write matching window do its usual job.
> + */
> + if (vcpu->arch.last_vmentry_cpu != -1 || vcpu->kvm->arch.user_set_tsc)
> + kvm_synchronize_tsc(vcpu, &tsc, false);
[Severity: High]
Does checking the VM-wide vcpu->kvm->arch.user_set_tsc flag here break TSC
synchronization when userspace configures or restores multiple never-run
vCPUs sequentially?
In __kvm_synchronize_tsc(), user_set_tsc is a VM-wide flag on struct kvm_arch:
if (user_set_tsc)
vcpu->kvm->arch.user_set_tsc = true;
If userspace initializes or restores vCPUs in a per-vCPU loop by calling
KVM_SET_TSC_KHZ followed by KVM_SET_MSRS(MSR_IA32_TSC) on each vCPU in turn:
1. Userspace creates vCPU 0 and vCPU 1 (both have last_vmentry_cpu == -1 and
creation-time TSC offsets ticking from ~0).
2. On vCPU 0, userspace calls KVM_SET_TSC_KHZ and then writes MSR_IA32_TSC
with a restored value T_restore (where T_restore > 1 second of guest
uptime). That sets vcpu->kvm->arch.user_set_tsc = true and sets
cur_tsc_write = T_restore.
3. On vCPU 1, before MSR_IA32_TSC is written on vCPU 1, userspace calls
KVM_SET_TSC_KHZ. Because the VM-wide user_set_tsc flag is already true,
kvm_set_tsc_khz() takes the first branch and passes vCPU 1's un-restored,
near-zero creation TSC (&tsc) instead of NULL.
4. In kvm_synchronize_tsc(), vCPU 1's near-zero tsc is more than 1 second
away from cur_tsc_write (T_restore), so it fails to match and opens a new
TSC generation with cur_tsc_write overwritten to that near-zero value.
5. When userspace then writes MSR_IA32_TSC = T_restore on vCPU 1, T_restore
is more than 1 second away from the clobbered near-zero cur_tsc_write, so
it fails to match again and leaves all_vcpus_matched_tsc false.
Should this check whether a TSC value was written by userspace on this
specific vCPU rather than checking the VM-wide vcpu->kvm->arch.user_set_tsc
(which is also read here without holding kvm->arch.tsc_write_lock)?
[Severity: Medium]
What happens in kvm_set_tsc_khz() when KVM_SET_TSC_KHZ is called on a
multi-vCPU guest whose vCPUs have already run (last_vmentry_cpu != -1), if
userspace has never explicitly written MSR_IA32_TSC?
Because kvm_set_tsc_khz() passes &tsc (non-zero) with user_initiated = false,
kvm->arch.user_set_tsc remains false. When kvm_synchronize_tsc() runs for each
vCPU:
if (vcpu->arch.virtual_tsc_khz) {
if (data == 0) {
synchronizing = true;
} else if (kvm->arch.user_set_tsc) {
...
}
}
Since data != 0 and kvm->arch.user_set_tsc is false, synchronizing is false
for every vCPU. Doesn't each vCPU open a separate TSC generation with
nr_vcpus_matched_tsc = 1, orphaning its siblings and leaving
all_vcpus_matched_tsc permanently false?
> + else
> + kvm_synchronize_tsc(vcpu, NULL, false);
> + return 0;
[Severity: High]
Can calling kvm_synchronize_tsc() unconditionally from kvm_set_tsc_khz()
corrupt VM-wide TSC matching state during KVM_CREATE_VCPU?
During vCPU creation, kvm_vm_ioctl_create_vcpu() calls:
kvm_vm_ioctl_create_vcpu()
-> kvm_arch_vcpu_create()
-> kvm_set_tsc_khz(vcpu, vcpu->kvm->arch.default_tsc_khz)
-> kvm_synchronize_tsc(vcpu, NULL, false)
-> __kvm_synchronize_tsc()
-> kvm_track_tsc_matching()
At the point kvm_arch_vcpu_create() runs, atomic_inc(&kvm->online_vcpus) has
not happened yet:
virt/kvm/kvm_main.c:kvm_vm_ioctl_create_vcpu() {
...
r = kvm_arch_vcpu_create(vcpu);
if (r)
goto vcpu_free_run_page;
...
smp_wmb();
atomic_inc(&kvm->online_vcpus);
mutex_unlock(&vcpu->mutex);
kvm_arch_vcpu_postcreate(vcpu);
}
Running __kvm_synchronize_tsc() and kvm_track_tsc_matching() before
online_vcpus is incremented appears to cause several regressions:
1. In kvm_track_tsc_matching():
int online = atomic_read(&vcpu->kvm->online_vcpus);
WRITE_ONCE(ka->all_vcpus_matched_tsc,
ka->nr_vcpus_matched_tsc >= online);
update_mclock |= (prev_matched_tsc != ka->all_vcpus_matched_tsc);
if (ka->all_vcpus_matched_tsc ||
ka->nr_vcpus_matched_freq >= online)
ka->all_vcpus_matched_freq = true;
If vCPU 0 is already online (online == 1) and configured to a non-default
frequency F != default_tsc_khz, creating vCPU 1 runs
__kvm_synchronize_tsc() at default_tsc_khz while online is still 1. That
resets ka->all_vcpus_matched_freq = false, increments
ka->nr_vcpus_matched_freq to 1, and sets ka->cur_tsc_khz = default_tsc_khz.
Then kvm_track_tsc_matching() sees nr_vcpus_matched_freq (1) >= online (1)
and latches ka->all_vcpus_matched_freq = true. When
kvm_arch_vcpu_postcreate() later runs with online == 2,
vcpu->arch.virtual_tsc_khz already equals ka->cur_tsc_khz, so
all_vcpus_matched_freq is never cleared and kvm_update_masterclock()
enables masterclock mode across frequency-mismatched vCPUs.
2. If userspace creates and configures vCPUs one by one (create vCPU 0, call
KVM_SET_TSC_KHZ(vcpu 0, F), then create vCPU 1, call
KVM_SET_TSC_KHZ(vcpu 1, F)), creating vCPU 1 synchronizes it at
default_tsc_khz, clobbering cur_tsc_khz, cur_tsc_offset,
cur_tsc_freq_generation, and cur_tsc_generation so that the subsequent
KVM_SET_TSC_KHZ(vcpu 1, F) only counts vCPU 1 and leaves
all_vcpus_matched_freq and all_vcpus_matched_tsc false.
3. If kvm_dirty_ring_alloc(), xa_insert(), or create_vcpu_fd() fails in
kvm_vm_ioctl_create_vcpu() after kvm_arch_vcpu_create(), the destroyed
vCPU's increments and generation changes in kvm->arch remain permanently
recorded.
Should kvm_set_tsc_khz() skip kvm_synchronize_tsc() during
kvm_arch_vcpu_create() and leave initial synchronization to
kvm_arch_vcpu_postcreate() after online_vcpus has been incremented?
[Severity: Medium]
Does the KVM_SET_TSC_KHZ ioctl path also need to process
KVM_REQ_MASTERCLOCK_UPDATE before returning to userspace?
Calling kvm_synchronize_tsc() from kvm_set_tsc_khz() updates
ka->cur_tsc_scaling_ratio and sets KVM_REQ_MASTERCLOCK_UPDATE on the vCPU via
kvm_track_tsc_matching(), but kvm_arch_vcpu_ioctl() returns to userspace
without calling kvm_update_masterclock().
In __get_kvmclock_master_clock(), get_kvmclock() uses
ka->master_tsc_scaling_ratio, ka->master_tsc_shift, and ka->master_tsc_mul,
which are only updated from ka->cur_tsc_scaling_ratio when
pvclock_update_vm_gtod_copy() runs via kvm_update_masterclock():
hv_clock.tsc_shift = ka->master_tsc_shift;
hv_clock.tsc_to_system_mul = ka->master_tsc_mul;
if (kvm_caps.has_tsc_control) {
u64 tsc_delta = data->host_tsc - ka->master_cycle_now;
tsc_delta = kvm_scale_tsc(tsc_delta, ka->master_tsc_scaling_ratio);
If userspace calls KVM_SET_TSC_KHZ and then queries KVM_GET_CLOCK before
entering KVM_RUN, won't get_kvmclock() still use the stale masterclock
scaling parameters (or remain in masterclock mode despite a frequency
mismatch)?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105154955.2525419-1-dwmw2@infradead.org?part=8
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v11 09/23] KVM: x86: Cache host vclock_mode for masterclock eligibility checks
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (7 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 08/23] KVM: x86: Re-synchronize TSC after KVM_SET_TSC_KHZ David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 15:49 ` [PATCH v11 10/23] KVM: x86: Remove pvclock_gtod_data and private timekeeping code David Woodhouse
` (13 subsequent siblings)
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
The remaining users of pvclock_gtod_data only need to know whether
the host clocksource is TSC-based. Cache the vclock_mode value in a
simple kvm_host_vclock_mode variable, updated by the pvclock_gtod_notify
callback, and use gtod_is_based_on_tsc() for eligibility checks.
This is inherently racy (as it always was — kvm_track_tsc_matching
never held the gtod seqcount), relying on eventual consistency: the
notifier fires on every timekeeping update and will correct any
transient inconsistency within one tick.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/kvm/x86.c | 27 +++++++++++++++++----------
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f551056d7274..e81e527e7b99 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1136,6 +1136,8 @@ static u64 compute_guest_tsc(struct kvm_vcpu *vcpu, s64 kernel_ns)
}
#ifdef CONFIG_X86_64
+static int kvm_host_vclock_mode;
+
static inline bool gtod_is_based_on_tsc(int mode)
{
return mode == VDSO_CLOCKMODE_TSC || mode == VDSO_CLOCKMODE_HVCLOCK;
@@ -1165,7 +1167,6 @@ static bool kvm_use_master_clock(struct kvm *kvm)
static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool update_mclock)
{
struct kvm_arch *ka = &vcpu->kvm->arch;
- struct pvclock_gtod_data *gtod = &pvclock_gtod_data;
bool prev_matched_tsc = ka->all_vcpus_matched_tsc;
/*
@@ -1209,8 +1210,9 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool update_mclock)
* are fine — each vCPU's pvclock has its own tsc_timestamp that
* accounts for its offset.
*/
+ int host_vclock_mode = READ_ONCE(kvm_host_vclock_mode);
bool use_master_clock = kvm_use_master_clock(vcpu->kvm) &&
- gtod_is_based_on_tsc(gtod->clock.vclock_mode);
+ gtod_is_based_on_tsc(host_vclock_mode);
/*
* Request a masterclock update if needed: toggling master clock,
@@ -1223,7 +1225,7 @@ static void kvm_track_tsc_matching(struct kvm_vcpu *vcpu, bool update_mclock)
trace_kvm_track_tsc(vcpu->vcpu_id, ka->nr_vcpus_matched_tsc,
atomic_read(&vcpu->kvm->online_vcpus),
- ka->use_master_clock, gtod->clock.vclock_mode);
+ ka->use_master_clock, host_vclock_mode);
}
#else
static inline void kvm_track_tsc_matching(struct kvm_vcpu *vcpu,
@@ -1394,7 +1396,7 @@ static inline bool kvm_check_tsc_unstable(void)
* TSC is marked unstable when we're running on Hyper-V,
* 'TSC page' clocksource is good.
*/
- if (pvclock_gtod_data.clock.vclock_mode == VDSO_CLOCKMODE_HVCLOCK)
+ if (READ_ONCE(kvm_host_vclock_mode) == VDSO_CLOCKMODE_HVCLOCK)
return false;
#endif
return check_tsc_unstable();
@@ -1689,7 +1691,6 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
{
#ifdef CONFIG_X86_64
struct kvm_arch *ka = &kvm->arch;
- int vclock_mode;
bool host_tsc_clocksource;
lockdep_assert_held(&kvm->arch.tsc_write_lock);
@@ -1729,9 +1730,9 @@ static void pvclock_update_vm_gtod_copy(struct kvm *kvm)
ka->use_master_clock = false;
}
- vclock_mode = pvclock_gtod_data.clock.vclock_mode;
- trace_kvm_update_master_clock(ka->use_master_clock, vclock_mode,
- ka->all_vcpus_matched_freq);
+ trace_kvm_update_master_clock(ka->use_master_clock,
+ READ_ONCE(kvm_host_vclock_mode),
+ ka->all_vcpus_matched_freq);
#endif
}
@@ -7089,17 +7090,23 @@ static DEFINE_IRQ_WORK(pvclock_irq_work, pvclock_irq_work_fn);
static int pvclock_gtod_notify(struct notifier_block *nb, unsigned long unused,
void *priv)
{
- struct pvclock_gtod_data *gtod = &pvclock_gtod_data;
struct timekeeper *tk = priv;
update_pvclock_gtod(tk);
+ /*
+ * Pairs with the READ_ONCE() in the lockless readers; the race is
+ * benign by design, relying on eventual consistency (the notifier
+ * fires on every timekeeping update).
+ */
+ WRITE_ONCE(kvm_host_vclock_mode, tk->tkr_mono.clock->vdso_clock_mode);
+
/*
* Disable master clock if host does not trust, or does not use,
* TSC based clocksource. Delegate queue_work() to irq_work as
* this is invoked with tk_core.seq write held.
*/
- if (!gtod_is_based_on_tsc(gtod->clock.vclock_mode) &&
+ if (!gtod_is_based_on_tsc(kvm_host_vclock_mode) &&
atomic_read(&kvm_guest_has_master_clock) != 0)
irq_work_queue(&pvclock_irq_work);
return 0;
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v11 10/23] KVM: x86: Remove pvclock_gtod_data and private timekeeping code
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (8 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 09/23] KVM: x86: Cache host vclock_mode for masterclock eligibility checks David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 15:49 ` [PATCH v11 11/23] KVM: x86: Activate master clock from kvm_arch_init_vm() David Woodhouse
` (12 subsequent siblings)
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
Remove the now-unused KVM-private timekeeping infrastructure:
- struct pvclock_clock and struct pvclock_gtod_data
- update_pvclock_gtod() and its seqcount-protected state copy
(the private readers were already removed when their last callers
went away)
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/kvm/x86.c | 56 ----------------------------------------------
1 file changed, 56 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e81e527e7b99..940168528721 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -889,60 +889,6 @@ static inline bool kvm_vcpu_exit_request(struct kvm_vcpu *vcpu)
kvm_request_pending(vcpu) || xfer_to_guest_mode_work_pending();
}
-#ifdef CONFIG_X86_64
-struct pvclock_clock {
- int vclock_mode;
- u64 cycle_last;
- u64 mask;
- u32 mult;
- u32 shift;
- u64 base_cycles;
- u64 offset;
-};
-
-struct pvclock_gtod_data {
- seqcount_t seq;
-
- struct pvclock_clock clock; /* extract of a clocksource struct */
- struct pvclock_clock raw_clock; /* extract of a clocksource struct */
-
- ktime_t offs_boot;
- u64 wall_time_sec;
-};
-
-static struct pvclock_gtod_data pvclock_gtod_data;
-
-static void update_pvclock_gtod(struct timekeeper *tk)
-{
- struct pvclock_gtod_data *vdata = &pvclock_gtod_data;
-
- write_seqcount_begin(&vdata->seq);
-
- /* copy pvclock gtod data */
- vdata->clock.vclock_mode = tk->tkr_mono.clock->vdso_clock_mode;
- vdata->clock.cycle_last = tk->tkr_mono.cycle_last;
- vdata->clock.mask = tk->tkr_mono.mask;
- vdata->clock.mult = tk->tkr_mono.mult;
- vdata->clock.shift = tk->tkr_mono.shift;
- vdata->clock.base_cycles = tk->tkr_mono.xtime_nsec;
- vdata->clock.offset = tk->tkr_mono.base;
-
- vdata->raw_clock.vclock_mode = tk->tkr_raw.clock->vdso_clock_mode;
- vdata->raw_clock.cycle_last = tk->tkr_raw.cycle_last;
- vdata->raw_clock.mask = tk->tkr_raw.mask;
- vdata->raw_clock.mult = tk->tkr_raw.mult;
- vdata->raw_clock.shift = tk->tkr_raw.shift;
- vdata->raw_clock.base_cycles = tk->tkr_raw.xtime_nsec;
- vdata->raw_clock.offset = tk->tkr_raw.base;
-
- vdata->wall_time_sec = tk->xtime_sec;
-
- vdata->offs_boot = tk->offs_boot;
-
- write_seqcount_end(&vdata->seq);
-}
-#endif
-
static s64 get_kvmclock_base_ns(void)
{
/* Count up from boot time, but with the frequency of the raw clock. */
@@ -7092,8 +7038,6 @@ static int pvclock_gtod_notify(struct notifier_block *nb, unsigned long unused,
{
struct timekeeper *tk = priv;
- update_pvclock_gtod(tk);
-
/*
* Pairs with the READ_ONCE() in the lockless readers; the race is
* benign by design, relying on eventual consistency (the notifier
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v11 11/23] KVM: x86: Activate master clock from kvm_arch_init_vm()
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (9 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 10/23] KVM: x86: Remove pvclock_gtod_data and private timekeeping code David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 19:15 ` sashiko-bot
2026-11-05 15:49 ` [PATCH v11 12/23] UAPI: x86: Move pvclock-abi to UAPI for x86 platforms David Woodhouse
` (11 subsequent siblings)
22 siblings, 1 reply; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
Initialize the TSC generation and master clock state at VM creation
time, rather than relying on kvm_update_masterclock() from
kvm_arch_vcpu_postcreate().
Set cur_tsc_generation=1, cur_tsc_khz, cur_tsc_scaling_ratio,
cur_tsc_offset, cur_tsc_nsec and kvmclock_offset from an atomic
ktime/TSC snapshot. This establishes a coherent epoch so that:
- The first vCPU synchronizes to the existing generation (getting
the pre-computed TSC offset) rather than computing its own.
- pvclock_update_vm_gtod_copy() succeeds immediately (no zero
tsc_hz from uninitialized cur_tsc_scaling_ratio).
- KVM_GET_CLOCK returns valid {host_tsc, realtime} fields as soon
as any vCPU exists.
- KVM_[GS]ET_CLOCK_GUEST works without a prior KVM_RUN.
- No O(N) iteration of all vCPUs on each vCPU creation.
This replaces the KVM_REQ_MASTERCLOCK_UPDATE check and
kvm_update_masterclock() call in kvm_arch_vcpu_postcreate(), which
worked around the missing initialization. A masterclock refresh is
still performed (synchronously, so that it is valid even for userspace
which queries the clock before ever running a vCPU) when the first
vCPU is created, since the VM-creation snapshot can go stale while the
VM has no vCPUs: a clocksource change notifies only VMs with vCPUs,
and a change back to TSC leaves nothing to disagree with the stale
snapshot.
The generation's recorded offset in kvm_synchronize_tsc() can now only
be joined by a vCPU with the same scaling ratio it was recorded with:
the initial generation's offset is recorded with the default ratio
before any vCPU exists, and a vCPU with a different ratio opens a new
generation with its own offset, keeping the generation's ratio and
offset describing the same scaling domain.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/kvm/x86.c | 76 ++++++++++++++++++++++++++++++++++++++--------
1 file changed, 64 insertions(+), 12 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 940168528721..6dbdb60962fe 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1500,11 +1500,25 @@ void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *value, bool user_initiated)
data = kvm->arch.cur_tsc_write + delta;
- if (!kvm_check_tsc_unstable())
- offset = kvm->arch.cur_tsc_offset;
- else
+ /*
+ * The generation's offset can only be joined by a vCPU which
+ * scales the TSC by the same ratio it was recorded with; the
+ * initial generation's offset is recorded at VM creation
+ * with the default ratio, before any vCPU exists. With a
+ * different ratio, open a new generation (recording this
+ * vCPU's own offset) rather than leave the generation's
+ * ratio and offset describing different scaling domains.
+ */
+ if (vcpu->arch.l1_tsc_scaling_ratio !=
+ kvm->arch.cur_tsc_scaling_ratio) {
offset = kvm_compute_l1_tsc_offset(vcpu, host_tsc, data);
- matched = true;
+ } else {
+ if (!kvm_check_tsc_unstable())
+ offset = kvm->arch.cur_tsc_offset;
+ else
+ offset = kvm_compute_l1_tsc_offset(vcpu, host_tsc, data);
+ matched = true;
+ }
}
__kvm_synchronize_tsc(vcpu, offset, data, ns, matched, user_initiated);
@@ -9645,8 +9659,15 @@ void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
return;
vcpu_load(vcpu);
kvm_synchronize_tsc(vcpu, NULL, false);
- if (kvm_check_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu))
+
+ /*
+ * Refresh the VM-creation masterclock snapshot (see
+ * kvm_arch_init_vm), synchronously so that it is valid even for
+ * userspace which queries the clock before ever running a vCPU.
+ */
+ if (vcpu->vcpu_idx == 0)
kvm_update_masterclock(vcpu->kvm, NULL);
+
vcpu_put(vcpu);
/* poll control enabled by default */
@@ -10065,6 +10086,8 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
{
int ret;
unsigned long flags;
+ u64 kvmclock_host_tsc;
+ s64 kvmclock_ns;
if (!kvm_is_vm_type_supported(type))
return -EINVAL;
@@ -10096,9 +10119,13 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
seqcount_raw_spinlock_init(&kvm->arch.pvclock_sc, &kvm->arch.tsc_write_lock);
ratelimit_state_init(&kvm->arch.kvmclock_update_rs, HZ, 10);
ratelimit_set_flags(&kvm->arch.kvmclock_update_rs, RATELIMIT_MSG_ON_RELEASE);
- kvm->arch.kvmclock_offset = -get_kvmclock_base_ns();
- kvm->arch.all_vcpus_matched_freq = true;
+ kvm->arch.default_tsc_khz = max_tsc_khz ? : tsc_khz;
+ kvm->arch.apic_bus_cycle_ns = APIC_BUS_CYCLE_NS_DEFAULT;
+ kvm->arch.guest_can_read_msr_platform_info = true;
+ kvm->arch.enable_pmu = enable_pmu && !kvm->arch.has_protected_pmu;
+
+ kvm->arch.all_vcpus_matched_freq = true;
/*
* Start with all (zero) vCPUs considered matched, so that a VM whose
* vCPUs never reach kvm_track_tsc_matching() — notably when the guest
@@ -10106,16 +10133,41 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
* returns early — is still eligible for PVCLOCK_TSC_STABLE_BIT.
*/
kvm->arch.all_vcpus_matched_tsc = true;
+ kvm->arch.cur_tsc_scaling_ratio = kvm_caps.default_tsc_scaling_ratio;
+ kvm->arch.cur_tsc_khz = kvm->arch.default_tsc_khz;
raw_spin_lock_irqsave(&kvm->arch.tsc_write_lock, flags);
+
+ /*
+ * Establish the initial TSC generation for synchronization logic.
+ * The first vCPU will sync to this, starting its guest TSC at the
+ * number of cycles elapsed since VM creation rather than at zero.
+ * This ensures coherence with the kvmclock epoch (also set here),
+ * and the master clock snapshot taken below is immediately valid.
+ * It is refreshed again when the first vCPU is created, in case
+ * the host clocksource changed (and changed back) in between:
+ * pvclock_gtod_update_fn() does not notify a VM with no vCPUs.
+ */
+#ifdef CONFIG_X86_64
+ if (!kvm_get_time_and_clockread(&kvmclock_ns, &kvmclock_host_tsc))
+#endif
+ {
+ /*
+ * If not simultaneous, we want the TSC to be zero slightly
+ * *after* the kvmclock is zero.
+ */
+ kvmclock_ns = get_kvmclock_base_ns();
+ kvmclock_host_tsc = rdtsc();
+ }
+ kvm->arch.cur_tsc_write = 0;
+ kvm->arch.cur_tsc_offset = -(s64)kvmclock_host_tsc;
+ kvm->arch.cur_tsc_nsec = kvmclock_ns;
+ kvm->arch.cur_tsc_generation = 1;
+ kvm->arch.kvmclock_offset = -kvmclock_ns;
+
pvclock_update_vm_gtod_copy(kvm);
raw_spin_unlock_irqrestore(&kvm->arch.tsc_write_lock, flags);
- kvm->arch.default_tsc_khz = max_tsc_khz ? : tsc_khz;
- kvm->arch.apic_bus_cycle_ns = APIC_BUS_CYCLE_NS_DEFAULT;
- kvm->arch.guest_can_read_msr_platform_info = true;
- kvm->arch.enable_pmu = enable_pmu && !kvm->arch.has_protected_pmu;
-
#if IS_ENABLED(CONFIG_HYPERV)
spin_lock_init(&kvm->arch.hv_root_tdp_lock);
kvm->arch.hv_root_tdp = INVALID_PAGE;
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v11 11/23] KVM: x86: Activate master clock from kvm_arch_init_vm()
2026-11-05 15:49 ` [PATCH v11 11/23] KVM: x86: Activate master clock from kvm_arch_init_vm() David Woodhouse
@ 2026-11-05 19:15 ` sashiko-bot
0 siblings, 0 replies; 33+ messages in thread
From: sashiko-bot @ 2026-11-05 19:15 UTC (permalink / raw)
To: David Woodhouse, kvm
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] KVM: x86: unreachable scaling check in kvm_synchronize_tsc()
- [Medium] KVM: x86: premature TSC sync in kvm_arch_vcpu_create() corrupts freq match
- [Medium] KVM: x86: unserviced masterclock request in kvm_arch_vcpu_postcreate()
--
commit e32eb6058695cc6d79a22be2b503c0c26e852ace
Author: David Woodhouse <dwmw@amazon.co.uk>
KVM: x86: Activate master clock from kvm_arch_init_vm()
This commit initializes the initial TSC generation and master clock state in
kvm_arch_init_vm() from an atomic ktime/TSC snapshot, and updates
kvm_synchronize_tsc() and kvm_arch_vcpu_postcreate() to synchronize vCPUs and
refresh the master clock against that initial generation.
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 9401685287215..6dbdb60962fe7 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1500,11 +1500,25 @@ void kvm_synchronize_tsc(struct kvm_vcpu *vcpu, u64 *value, bool user_initiated)
>
> data = kvm->arch.cur_tsc_write + delta;
>
> - if (!kvm_check_tsc_unstable())
> - offset = kvm->arch.cur_tsc_offset;
> - else
> + /*
> + * The generation's offset can only be joined by a vCPU which
> + * scales the TSC by the same ratio it was recorded with; the
> + * initial generation's offset is recorded at VM creation
> + * with the default ratio, before any vCPU exists. With a
> + * different ratio, open a new generation (recording this
> + * vCPU's own offset) rather than leave the generation's
> + * ratio and offset describing different scaling domains.
> + */
> + if (vcpu->arch.l1_tsc_scaling_ratio !=
> + kvm->arch.cur_tsc_scaling_ratio) {
> offset = kvm_compute_l1_tsc_offset(vcpu, host_tsc, data);
> - matched = true;
> + } else {
> + if (!kvm_check_tsc_unstable())
> + offset = kvm->arch.cur_tsc_offset;
> + else
> + offset = kvm_compute_l1_tsc_offset(vcpu, host_tsc, data);
> + matched = true;
> + }
> }
>
> __kvm_synchronize_tsc(vcpu, offset, data, ns, matched, user_initiated);
[Severity: Medium]
Can this scaling ratio check in kvm_synchronize_tsc() ever be reached?
The enclosing block in kvm_synchronize_tsc() is gated on matching
virtual_tsc_khz:
if (synchronizing &&
vcpu->arch.virtual_tsc_khz == kvm->arch.cur_tsc_khz) {
u64 delta = nsec_to_cycles(vcpu, elapsed);
data = kvm->arch.cur_tsc_write + delta;
...
if (vcpu->arch.l1_tsc_scaling_ratio !=
kvm->arch.cur_tsc_scaling_ratio) {
In set_tsc_khz(), vcpu->arch.l1_tsc_scaling_ratio is derived deterministically
from vcpu->arch.virtual_tsc_khz, and __kvm_synchronize_tsc() updates
kvm->arch.cur_tsc_khz and kvm->arch.cur_tsc_scaling_ratio together.
Meanwhile, kvm_arch_init_vm() initializes:
kvm->arch.cur_tsc_scaling_ratio = kvm_caps.default_tsc_scaling_ratio;
kvm->arch.cur_tsc_khz = kvm->arch.default_tsc_khz;
When userspace configures a non-default guest TSC frequency via the VM-scoped
KVM_SET_TSC_KHZ ioctl in kvm_arch_vm_ioctl():
mutex_lock(&kvm->lock);
if (!kvm->created_vcpus) {
WRITE_ONCE(kvm->arch.default_tsc_khz, user_tsc_khz);
r = 0;
}
mutex_unlock(&kvm->lock);
only kvm->arch.default_tsc_khz is updated, leaving kvm->arch.cur_tsc_khz at
the initial host frequency. Or, if userspace instead invokes the vCPU-scoped
KVM_SET_TSC_KHZ ioctl after creating the first vCPU, virtual_tsc_khz also
differs from kvm->arch.cur_tsc_khz.
In both cases, vcpu->arch.virtual_tsc_khz == kvm->arch.cur_tsc_khz is false in
kvm_synchronize_tsc(), so the outer if block is skipped entirely. That leaves
data at 0 instead of extrapolating data = kvm->arch.cur_tsc_write + delta from
the VM-creation epoch (while kvmclock_offset remains anchored at VM creation
time), and on VMs where vcpu->arch.guest_tsc_protected causes
__kvm_synchronize_tsc() to return early, kvm->arch.cur_tsc_scaling_ratio and
kvm->arch.master_tsc_scaling_ratio remain stuck at
kvm_caps.default_tsc_scaling_ratio.
> @@ -9645,8 +9659,15 @@ void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
> return;
> vcpu_load(vcpu);
> kvm_synchronize_tsc(vcpu, NULL, false);
> - if (kvm_check_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu))
> +
> + /*
> + * Refresh the VM-creation masterclock snapshot (see
> + * kvm_arch_init_vm), synchronously so that it is valid even for
> + * userspace which queries the clock before ever running a vCPU.
> + */
> + if (vcpu->vcpu_idx == 0)
> kvm_update_masterclock(vcpu->kvm, NULL);
> +
> vcpu_put(vcpu);
>
> /* poll control enabled by default */
[Severity: Medium]
What happens if creating a secondary vCPU (vcpu->vcpu_idx > 0) queues
KVM_REQ_MASTERCLOCK_UPDATE on that vCPU?
During vCPU creation, kvm_synchronize_tsc() -> __kvm_synchronize_tsc() ->
kvm_track_tsc_matching() checks whether a masterclock update is needed:
if ((ka->use_master_clock && update_mclock) ||
(ka->use_master_clock != use_master_clock))
kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu);
When vcpu->vcpu_idx > 0 and its synchronization opens a new TSC generation,
changes ka->all_vcpus_matched_tsc, or changes masterclock eligibility,
KVM_REQ_MASTERCLOCK_UPDATE is queued only on the newly created vCPU.
With kvm_arch_vcpu_postcreate() only calling kvm_update_masterclock() when
vcpu->vcpu_idx == 0, won't that request remain unserviced until the secondary
vCPU enters vcpu_enter_guest(), leaving ka->use_master_clock and the
masterclock state stale for host-side KVM_GET_CLOCK / KVM_GET_CLOCK_GUEST /
KVM_SET_CLOCK_GUEST calls and delaying KVM_REQ_CLOCK_UPDATE for already
running sibling vCPUs?
> @@ -10106,16 +10133,41 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
> * returns early — is still eligible for PVCLOCK_TSC_STABLE_BIT.
> */
> kvm->arch.all_vcpus_matched_tsc = true;
> + kvm->arch.cur_tsc_scaling_ratio = kvm_caps.default_tsc_scaling_ratio;
> + kvm->arch.cur_tsc_khz = kvm->arch.default_tsc_khz;
>
> raw_spin_lock_irqsave(&kvm->arch.tsc_write_lock, flags);
> +
> + /*
> + * Establish the initial TSC generation for synchronization logic.
> + * The first vCPU will sync to this, starting its guest TSC at the
> + * number of cycles elapsed since VM creation rather than at zero.
> + * This ensures coherence with the kvmclock epoch (also set here),
> + * and the master clock snapshot taken below is immediately valid.
> + * It is refreshed again when the first vCPU is created, in case
> + * the host clocksource changed (and changed back) in between:
> + * pvclock_gtod_update_fn() does not notify a VM with no vCPUs.
> + */
> +#ifdef CONFIG_X86_64
> + if (!kvm_get_time_and_clockread(&kvmclock_ns, &kvmclock_host_tsc))
> +#endif
> + {
> + /*
> + * If not simultaneous, we want the TSC to be zero slightly
> + * *after* the kvmclock is zero.
> + */
> + kvmclock_ns = get_kvmclock_base_ns();
> + kvmclock_host_tsc = rdtsc();
> + }
> + kvm->arch.cur_tsc_write = 0;
> + kvm->arch.cur_tsc_offset = -(s64)kvmclock_host_tsc;
> + kvm->arch.cur_tsc_nsec = kvmclock_ns;
> + kvm->arch.cur_tsc_generation = 1;
> + kvm->arch.kvmclock_offset = -kvmclock_ns;
[Severity: Medium]
Now that cur_tsc_khz and cur_tsc_generation are initialized from
kvm_arch_init_vm() with all_vcpus_matched_freq = true and
all_vcpus_matched_tsc = true, does the initial kvm_set_tsc_khz() call in
kvm_arch_vcpu_create() corrupt frequency and TSC matching when userspace uses
per-vCPU KVM_SET_TSC_KHZ?
In kvm_vm_ioctl_create_vcpu(), kvm_arch_vcpu_create() runs before
atomic_inc(&kvm->online_vcpus):
kvm_arch_vcpu_create(vcpu)
kvm_set_tsc_khz(vcpu, vcpu->kvm->arch.default_tsc_khz)
set_tsc_khz(vcpu, user_tsc_khz, false)
kvm_synchronize_tsc(vcpu, NULL, false)
Consider creating vCPU 0 and setting its frequency to F != default_tsc_khz via
the vCPU-scoped KVM_SET_TSC_KHZ ioctl (so cur_tsc_khz = F,
cur_tsc_freq_generation = 1, and nr_vcpus_matched_freq = 1), and then creating
vCPU 1:
1. In kvm_arch_vcpu_create(vcpu 1), kvm_set_tsc_khz() syncs vCPU 1 at
default_tsc_khz while online_vcpus is still 1. Because default_tsc_khz != F,
__kvm_synchronize_tsc() increments cur_tsc_freq_generation to 2, clears
all_vcpus_matched_freq, sets nr_vcpus_matched_freq = 1, and overwrites
cur_tsc_khz = default_tsc_khz.
2. Immediately afterwards, kvm_track_tsc_matching() reads online = 1, sees
nr_vcpus_matched_freq (1) >= online (1), and sets
ka->all_vcpus_matched_freq = true.
3. After online_vcpus is incremented to 2, kvm_arch_vcpu_postcreate(vcpu 1)
calls kvm_synchronize_tsc(vcpu 1, NULL, false). Because vCPU 1's
virtual_tsc_khz already matches cur_tsc_khz (default_tsc_khz),
__kvm_synchronize_tsc() does not clear all_vcpus_matched_freq.
If vCPU 1 is left at default_tsc_khz, all_vcpus_matched_freq remains true even
though vCPU 0 is at F and vCPU 1 is at default_tsc_khz. Conversely, if
userspace then sets vCPU 1's frequency to F via KVM_SET_TSC_KHZ, the
intermediate sync at default_tsc_khz has already bumped
cur_tsc_freq_generation and cur_tsc_generation, so setting vCPU 1 to F bumps
both generations again with nr_vcpus_matched_freq = 1 and
nr_vcpus_matched_tsc = 1 (for 2 online vCPUs), leaving all_vcpus_matched_freq
and all_vcpus_matched_tsc permanently false even though both vCPUs are
configured to F.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105154955.2525419-1-dwmw2@infradead.org?part=11
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v11 12/23] UAPI: x86: Move pvclock-abi to UAPI for x86 platforms
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (10 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 11/23] KVM: x86: Activate master clock from kvm_arch_init_vm() David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 15:49 ` [PATCH v11 13/23] KVM: selftests: Use UAPI pvclock-abi.h in xen_shinfo_test David Woodhouse
` (10 subsequent siblings)
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: Jack Allister <jalliste@amazon.com>
A subsequent commit will provide a new KVM interface for performing a
fixup/correction of the KVM clock against the reference TSC. The
KVM_[GS]ET_CLOCK_GUEST API requires a pvclock_vcpu_time_info, as such
the caller must know about this definition.
Move the definition to the UAPI folder so that it is exported to
usermode, change the type definitions to use the standard for UAPI
exports, and add the Linux-syscall-note exception to the SPDX licence
identifier as is conventional for exported headers.
Define __KERNEL__ in scripts/xen-hypercalls.sh: the UAPI header now
pulls in linux/types.h, and the script's raw $CPP invocation with
$LINUXINCLUDE does not define it, which would trigger the "attempt to
use kernel headers from user space" warning from the UAPI type
headers.
Signed-off-by: Jack Allister <jalliste@amazon.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
Tested-by: Dongli Zhang <dongli.zhang@oracle.com>
---
MAINTAINERS | 4 +--
arch/x86/include/{ => uapi}/asm/pvclock-abi.h | 27 ++++++++++---------
scripts/xen-hypercalls.sh | 2 +-
3 files changed, 18 insertions(+), 15 deletions(-)
rename arch/x86/include/{ => uapi}/asm/pvclock-abi.h (82%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9fadc98d3c49..773f7c800f6a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14663,8 +14663,8 @@ S: Supported
T: git git://git.kernel.org/pub/scm/virt/kvm/kvm.git
F: arch/um/include/asm/kvm_para.h
F: arch/x86/include/asm/kvm_para.h
-F: arch/x86/include/asm/pvclock-abi.h
F: arch/x86/include/uapi/asm/kvm_para.h
+F: arch/x86/include/uapi/asm/pvclock-abi.h
F: arch/x86/kernel/kvm.c
F: arch/x86/kernel/kvmclock.c
F: include/asm-generic/kvm_para.h
@@ -29780,8 +29780,8 @@ R: Boris Ostrovsky <boris.ostrovsky@oracle.com>
L: xen-devel@lists.xenproject.org (moderated for non-subscribers)
S: Supported
F: arch/x86/configs/xen.config
-F: arch/x86/include/asm/pvclock-abi.h
F: arch/x86/include/asm/xen/
+F: arch/x86/include/uapi/asm/pvclock-abi.h
F: arch/x86/platform/pvh/
F: arch/x86/xen/
diff --git a/arch/x86/include/asm/pvclock-abi.h b/arch/x86/include/uapi/asm/pvclock-abi.h
similarity index 82%
rename from arch/x86/include/asm/pvclock-abi.h
rename to arch/x86/include/uapi/asm/pvclock-abi.h
index b9fece5fc96d..6d70cf640362 100644
--- a/arch/x86/include/asm/pvclock-abi.h
+++ b/arch/x86/include/uapi/asm/pvclock-abi.h
@@ -1,6 +1,9 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
#ifndef _ASM_X86_PVCLOCK_ABI_H
#define _ASM_X86_PVCLOCK_ABI_H
+
+#include <linux/types.h>
+
#ifndef __ASSEMBLER__
/*
@@ -24,20 +27,20 @@
*/
struct pvclock_vcpu_time_info {
- u32 version;
- u32 pad0;
- u64 tsc_timestamp;
- u64 system_time;
- u32 tsc_to_system_mul;
- s8 tsc_shift;
- u8 flags;
- u8 pad[2];
+ __u32 version;
+ __u32 pad0;
+ __u64 tsc_timestamp;
+ __u64 system_time;
+ __u32 tsc_to_system_mul;
+ __s8 tsc_shift;
+ __u8 flags;
+ __u8 pad[2];
} __attribute__((__packed__)); /* 32 bytes */
struct pvclock_wall_clock {
- u32 version;
- u32 sec;
- u32 nsec;
+ __u32 version;
+ __u32 sec;
+ __u32 nsec;
} __attribute__((__packed__));
#define PVCLOCK_TSC_STABLE_BIT (1 << 0)
diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
index f18b00843df3..51a722198997 100755
--- a/scripts/xen-hypercalls.sh
+++ b/scripts/xen-hypercalls.sh
@@ -5,7 +5,7 @@ shift
in="$@"
for i in $in; do
- eval $CPP $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
+ eval $CPP -D__KERNEL__ $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
done | \
awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
END { print "/* auto-generated by scripts/xen-hypercall.sh */"
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v11 13/23] KVM: selftests: Use UAPI pvclock-abi.h in xen_shinfo_test
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (11 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 12/23] UAPI: x86: Move pvclock-abi to UAPI for x86 platforms David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 15:49 ` [PATCH v11 14/23] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate KVM clock migration David Woodhouse
` (9 subsequent siblings)
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
Now that pvclock-abi.h is a UAPI header, use it in xen_shinfo_test.c
instead of locally duplicating the struct definitions.
Sync the tools/ mirror of the header to the UAPI content: the KVM
selftests include path puts tools/arch/x86/include ahead of the
installed kernel headers, so the mirror is what actually gets used.
That makes the struct fields __u64 (unsigned long long), so switch
the verbose printfs away from PRIu64, which is "lu" on 64-bit.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
tools/arch/x86/include/asm/pvclock-abi.h | 27 +++++++++-------
.../selftests/kvm/x86/xen_shinfo_test.c | 31 ++++++-------------
2 files changed, 24 insertions(+), 34 deletions(-)
diff --git a/tools/arch/x86/include/asm/pvclock-abi.h b/tools/arch/x86/include/asm/pvclock-abi.h
index b9fece5fc96d..6d70cf640362 100644
--- a/tools/arch/x86/include/asm/pvclock-abi.h
+++ b/tools/arch/x86/include/asm/pvclock-abi.h
@@ -1,6 +1,9 @@
-/* SPDX-License-Identifier: GPL-2.0 */
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
#ifndef _ASM_X86_PVCLOCK_ABI_H
#define _ASM_X86_PVCLOCK_ABI_H
+
+#include <linux/types.h>
+
#ifndef __ASSEMBLER__
/*
@@ -24,20 +27,20 @@
*/
struct pvclock_vcpu_time_info {
- u32 version;
- u32 pad0;
- u64 tsc_timestamp;
- u64 system_time;
- u32 tsc_to_system_mul;
- s8 tsc_shift;
- u8 flags;
- u8 pad[2];
+ __u32 version;
+ __u32 pad0;
+ __u64 tsc_timestamp;
+ __u64 system_time;
+ __u32 tsc_to_system_mul;
+ __s8 tsc_shift;
+ __u8 flags;
+ __u8 pad[2];
} __attribute__((__packed__)); /* 32 bytes */
struct pvclock_wall_clock {
- u32 version;
- u32 sec;
- u32 nsec;
+ __u32 version;
+ __u32 sec;
+ __u32 nsec;
} __attribute__((__packed__));
#define PVCLOCK_TSC_STABLE_BIT (1 << 0)
diff --git a/tools/testing/selftests/kvm/x86/xen_shinfo_test.c b/tools/testing/selftests/kvm/x86/xen_shinfo_test.c
index aaa414c677ad..c48c0bf44257 100644
--- a/tools/testing/selftests/kvm/x86/xen_shinfo_test.c
+++ b/tools/testing/selftests/kvm/x86/xen_shinfo_test.c
@@ -98,22 +98,7 @@ struct sched_poll {
u64 timeout;
};
-struct pvclock_vcpu_time_info {
- u32 version;
- u32 pad0;
- u64 tsc_timestamp;
- u64 system_time;
- u32 tsc_to_system_mul;
- s8 tsc_shift;
- u8 flags;
- u8 pad[2];
-} __attribute__((__packed__)); /* 32 bytes */
-
-struct pvclock_wall_clock {
- u32 version;
- u32 sec;
- u32 nsec;
-} __attribute__((__packed__));
+#include <asm/pvclock-abi.h>
struct vcpu_runstate_info {
u32 state;
@@ -987,12 +972,14 @@ int main(int argc, char *argv[])
if (verbose) {
printf("Wall clock (v %d) %d.%09d\n", wc->version, wc->sec, wc->nsec);
- printf("Time info 1: v %u tsc %" PRIu64 " time %" PRIu64 " mul %u shift %u flags %x\n",
- ti->version, ti->tsc_timestamp, ti->system_time, ti->tsc_to_system_mul,
- ti->tsc_shift, ti->flags);
- printf("Time info 2: v %u tsc %" PRIu64 " time %" PRIu64 " mul %u shift %u flags %x\n",
- ti2->version, ti2->tsc_timestamp, ti2->system_time, ti2->tsc_to_system_mul,
- ti2->tsc_shift, ti2->flags);
+ printf("Time info 1: v %u tsc %llu time %llu mul %u shift %u flags %x\n",
+ ti->version, (unsigned long long)ti->tsc_timestamp,
+ (unsigned long long)ti->system_time,
+ ti->tsc_to_system_mul, ti->tsc_shift, ti->flags);
+ printf("Time info 2: v %u tsc %llu time %llu mul %u shift %u flags %x\n",
+ ti2->version, (unsigned long long)ti2->tsc_timestamp,
+ (unsigned long long)ti2->system_time,
+ ti2->tsc_to_system_mul, ti2->tsc_shift, ti2->flags);
}
TEST_ASSERT(wc->version && !(wc->version & 1),
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v11 14/23] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate KVM clock migration
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (12 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 13/23] KVM: selftests: Use UAPI pvclock-abi.h in xen_shinfo_test David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 19:51 ` sashiko-bot
2026-11-05 15:49 ` [PATCH v11 15/23] KVM: selftests: Add library helpers for clock and TSC-offset ioctls David Woodhouse
` (8 subsequent siblings)
22 siblings, 1 reply; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: Jack Allister <jalliste@amazon.com>
In the common case (where kvm->arch.use_master_clock is true), the KVM
clock is defined as a simple arithmetic function of the guest TSC, based
on a reference point stored in kvm->arch.master_kernel_ns and
kvm->arch.master_cycle_now.
The existing KVM_[GS]ET_CLOCK functionality does not allow for this
relationship to be precisely saved and restored by userspace. All it can
currently do is set the KVM clock at a given UTC reference time, which
is necessarily imprecise.
So on live update, the guest TSC can remain cycle accurate at precisely
the same offset from the host TSC, but there is no way for userspace to
restore the KVM clock accurately.
Even on live migration to a new host, where the accuracy of the guest
time-keeping is fundamentally limited by the accuracy of wallclock
synchronization between the source and destination hosts, the clock jump
experienced by the guest's TSC and its KVM clock should at least be
*consistent*. Even when the guest TSC suffers a discontinuity, its KVM
clock should still remain the *same* arithmetic function of the guest
TSC, and not suffer an *additional* discontinuity.
To allow for accurate migration of the KVM clock, add per-vCPU ioctls
which save and restore the actual PV clock info in
pvclock_vcpu_time_info.
The restoration in KVM_SET_CLOCK_GUEST works by creating a new reference
point in time just as kvm_update_masterclock() does, and calculating the
corresponding guest TSC value. This guest TSC value is then passed
through the user-provided pvclock structure to generate the *intended*
KVM clock value at that point in time, and through the *actual* KVM
clock calculation. Then kvm->arch.kvmclock_offset is adjusted to
eliminate the difference.
Where kvm->arch.use_master_clock is false (because the host TSC is
unreliable, or the guest TSCs are configured strangely), the KVM clock
is *not* defined as a function of the guest TSC so KVM_GET_CLOCK_GUEST
returns an error. In this case, as documented, userspace shall use the
legacy KVM_GET_CLOCK ioctl. The loss of precision is acceptable in this
case since the clocks are imprecise in this mode anyway.
On *restoration*, if kvm->arch.use_master_clock is false, an error is
returned for similar reasons and userspace shall fall back to using
KVM_SET_CLOCK. This does mean that, as documented, userspace needs to
use *both* KVM_GET_CLOCK_GUEST and KVM_GET_CLOCK and send both results
with the migration data (unless the intent is to refuse to resume on a
host with bad TSC).
Both ioctls return -ENODATA when the KVM clock is not in master clock
mode. KVM_SET_CLOCK_GUEST can also return -EBUSY when the TSC frequency
of the current CPU is unknown (a hotplug window which exists only on
hosts without CONSTANT_TSC — which are unlikely ever to be in master
clock mode anyway, so userspace should treat -EBUSY like -ENODATA and
fall back to KVM_SET_CLOCK rather than retrying in a time-critical
path). KVM_GET_CLOCK_GUEST computes its result purely from the master
clock state and needs no per-CPU TSC frequency, so it cannot hit that
window. Advertise the ioctls with KVM_CAP_CLOCK_GUEST so that userspace
need not probe for them.
Co-developed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Jack Allister <jalliste@amazon.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Cc: Dongli Zhang <dongli.zhang@oracle.com>
Tested-by: Dongli Zhang <dongli.zhang@oracle.com>
---
Documentation/virt/kvm/api.rst | 54 ++++++++++
arch/x86/include/uapi/asm/kvm.h | 1 +
arch/x86/kvm/x86.c | 173 ++++++++++++++++++++++++++++++++
include/uapi/linux/kvm.h | 4 +
4 files changed, 232 insertions(+)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index ddc61ea36ac5..91406381c195 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -6759,6 +6759,60 @@ if the guest_memfd memory was pinned in IOMMU page tables.
See also: :ref:`KVM_SET_MEMORY_ATTRIBUTES`.
+4.147 KVM_GET_CLOCK_GUEST
+----------------------------
+
+:Capability: KVM_CAP_CLOCK_GUEST
+:Architectures: x86_64
+:Type: vcpu ioctl
+:Parameters: struct pvclock_vcpu_time_info (out)
+:Returns: 0 on success, <0 on error
+
+Retrieves the current time information structure used for KVM/PV clocks,
+in precisely the form advertised to the guest vCPU, which gives parameters
+for a direct conversion from a guest TSC value to nanoseconds.
+
+The structure is in terms of the given vCPU's TSC. It must be passed back
+to KVM_SET_CLOCK_GUEST on the *same* vCPU (on the destination VM, for
+migration); vCPUs may legitimately have different TSC offsets, which would
+otherwise be silently folded into the restored KVM clock.
+
+When the KVM clock is not in "master clock" mode, for example because the
+host TSC is unreliable or the guest TSCs are oddly configured, the KVM clock
+is actually defined by the host CLOCK_MONOTONIC_RAW instead of the guest TSC.
+In this case, the KVM_GET_CLOCK_GUEST ioctl returns -ENODATA.
+
+4.148 KVM_SET_CLOCK_GUEST
+----------------------------
+
+:Capability: KVM_CAP_CLOCK_GUEST
+:Architectures: x86_64
+:Type: vcpu ioctl
+:Parameters: struct pvclock_vcpu_time_info (in)
+:Returns: 0 on success, <0 on error
+
+Sets the KVM clock (for the whole VM) in terms of the vCPU TSC, using the
+pvclock structure as returned by KVM_GET_CLOCK_GUEST. This allows the precise
+arithmetic relationship between guest TSC and KVM clock to be preserved by
+userspace across migration.
+
+When the KVM clock is not in "master clock" mode, and the KVM clock is actually
+defined by the host CLOCK_MONOTONIC_RAW, this ioctl returns -ENODATA. Userspace
+may choose to set the clock using the less precise KVM_SET_CLOCK ioctl, or may
+choose to fail, denying migration to a host whose TSC is misbehaving. An -EBUSY
+return indicates that the TSC frequency of the current CPU is unknown, which is
+only possible on hosts without X86_FEATURE_CONSTANT_TSC; such hosts are unlikely
+to be in "master clock" mode anyway, and userspace should treat it the same as
+-ENODATA rather than retrying.
+
+If the mul/shift fields of the provided pvclock structure encode a TSC
+frequency inconsistent with the vCPU's actual TSC frequency, this ioctl
+returns -ERANGE.
+
+If the vCPU's current TSC is behind the tsc_timestamp in the provided
+structure, this ioctl returns -EINVAL. Restore the guest TSC (which the
+documented migration procedure keeps monotonic) before invoking it.
+
.. _kvm_run:
5. The kvm_run structure
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 1585ec804066..9e3cdc3adb65 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -12,6 +12,7 @@
#include <linux/types.h>
#include <linux/ioctl.h>
#include <linux/stddef.h>
+#include <asm/pvclock-abi.h>
#define KVM_PIO_PAGE_OFFSET 1
#define KVM_COALESCED_MMIO_PAGE_OFFSET 2
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 6dbdb60962fe..bdc838b12fdc 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2409,6 +2409,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_MEMORY_FAULT_INFO:
case KVM_CAP_X86_GUEST_MODE:
case KVM_CAP_ONE_REG:
+#ifdef CONFIG_X86_64
+ case KVM_CAP_CLOCK_GUEST:
+#endif
r = 1;
break;
case KVM_CAP_PRE_FAULT_MEMORY:
@@ -3541,6 +3544,168 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
}
}
+#ifdef CONFIG_X86_64
+static int kvm_vcpu_ioctl_get_clock_guest(struct kvm_vcpu *v, void __user *argp)
+{
+ struct pvclock_vcpu_time_info hv_clock = {};
+ struct kvm_arch *ka = &v->kvm->arch;
+ unsigned int seq;
+
+ /*
+ * Construct the pvclock purely from the master clock state. The
+ * master mul/shift are computed for the guest TSC frequency, which
+ * in master clock mode is the frequency of every vCPU; only the
+ * tsc_timestamp is per-vCPU, translating the master snapshot into
+ * this vCPU's TSC domain via its scaling ratio and offset.
+ *
+ * Note, this deliberately does NOT invoke kvm_guest_time_update(),
+ * which would write the guest's pvclock pages: dirtying guest
+ * memory after the final KVM_RUN would break post-copy migration
+ * flows. The pvclock returned here describes the same clock as the
+ * guest-visible copy (the same linear function of the guest TSC),
+ * anchored at the current master clock snapshot.
+ */
+ do {
+ seq = read_seqcount_begin(&ka->pvclock_sc);
+
+ if (!ka->use_master_clock)
+ return -ENODATA;
+
+ hv_clock.tsc_timestamp = kvm_read_l1_tsc(v, ka->master_cycle_now);
+ hv_clock.system_time = ka->master_kernel_ns + ka->kvmclock_offset;
+ hv_clock.tsc_shift = ka->master_tsc_shift;
+ hv_clock.tsc_to_system_mul = ka->master_tsc_mul;
+ hv_clock.flags = READ_ONCE(ka->all_vcpus_matched_tsc) ?
+ PVCLOCK_TSC_STABLE_BIT : 0;
+ } while (read_seqcount_retry(&ka->pvclock_sc, seq));
+
+ if (copy_to_user(argp, &hv_clock, sizeof(hv_clock)))
+ return -EFAULT;
+
+ return 0;
+}
+
+/*
+ * Reverse the calculation in the hv_clock definition.
+ *
+ * time_ns = ( (cycles << shift) * mul ) >> 32;
+ * (although shift can be negative, so that's bad C)
+ *
+ * So for a single second,
+ * NSEC_PER_SEC = ( ( FREQ_HZ << shift) * mul ) >> 32
+ * NSEC_PER_SEC << 32 = ( FREQ_HZ << shift ) * mul
+ * ( NSEC_PER_SEC << 32 ) / mul = FREQ_HZ << shift
+ * ( NSEC_PER_SEC << 32 ) / mul ) >> shift = FREQ_HZ
+ */
+static u64 hvclock_to_hz(u32 mul, s8 shift)
+{
+ u64 tm = NSEC_PER_SEC << 32;
+
+ /* Maximise precision. Shift left until the top bit is set */
+ tm <<= 2;
+ shift += 2;
+
+ /* While 'mul' is even, increase the shift *after* the division */
+ while (!(mul & 1)) {
+ shift++;
+ mul >>= 1;
+ }
+
+ tm /= mul;
+
+ if (shift >= 64)
+ return 0;
+ if (shift > 0)
+ return tm >> shift;
+ if (shift <= -64)
+ return 0;
+ return tm << -shift;
+}
+
+static int kvm_vcpu_ioctl_set_clock_guest(struct kvm_vcpu *v, void __user *argp)
+{
+ struct pvclock_vcpu_time_info user_hv_clock;
+ struct kvm *kvm = v->kvm;
+ struct kvm_arch *ka = &kvm->arch;
+ u64 curr_tsc_hz, user_tsc_hz;
+ u64 user_clk_ns;
+ u64 guest_tsc;
+ int rc = 0;
+
+ if (copy_from_user(&user_hv_clock, argp, sizeof(user_hv_clock)))
+ return -EFAULT;
+
+ if (user_hv_clock.pad0 || user_hv_clock.pad[0] || user_hv_clock.pad[1])
+ return -EINVAL;
+
+ if (!user_hv_clock.tsc_to_system_mul)
+ return -EINVAL;
+
+ if (user_hv_clock.tsc_shift < -31 || user_hv_clock.tsc_shift > 31)
+ return -EINVAL;
+
+ user_tsc_hz = hvclock_to_hz(user_hv_clock.tsc_to_system_mul,
+ user_hv_clock.tsc_shift);
+
+ kvm_hv_request_tsc_page_update(kvm);
+
+ /*
+ * kvm_start_pvclock_update() takes tsc_write_lock and opens
+ * the pvclock seqcount; kvm_end_pvclock_update() closes both.
+ * All clock state modifications between them are atomic with
+ * respect to readers in kvm_guest_time_update().
+ */
+ kvm_start_pvclock_update(kvm);
+ pvclock_update_vm_gtod_copy(kvm);
+
+ if (!ka->use_master_clock) {
+ rc = -ENODATA;
+ goto out;
+ }
+
+ curr_tsc_hz = (u64)get_cpu_tsc_khz() * HZ_PER_KHZ;
+ if (unlikely(curr_tsc_hz == 0)) {
+ rc = -EBUSY;
+ goto out;
+ }
+
+ if (kvm_caps.has_tsc_control)
+ curr_tsc_hz = kvm_scale_tsc(curr_tsc_hz,
+ v->arch.l1_tsc_scaling_ratio);
+
+ /*
+ * The mul/shift in the provided pvclock structure encode the guest
+ * TSC frequency at which it was generated. Sanity-check that it is
+ * consistent with this vCPU's effective TSC frequency, allowing a
+ * discrepancy of 1 kHz either way since independently calibrated
+ * hosts will not measure precisely the same value even for the
+ * same nominal frequency.
+ */
+ if (user_tsc_hz < curr_tsc_hz - 1000 ||
+ user_tsc_hz > curr_tsc_hz + 1000) {
+ rc = -ERANGE;
+ goto out;
+ }
+
+ /*
+ * Calculate the guest TSC at the new reference point, and the
+ * corresponding KVM clock value according to user_hv_clock.
+ * Adjust kvmclock_offset so both definitions agree.
+ */
+ guest_tsc = kvm_read_l1_tsc(v, ka->master_cycle_now);
+ if (guest_tsc < user_hv_clock.tsc_timestamp) {
+ rc = -EINVAL;
+ goto out;
+ }
+ user_clk_ns = __pvclock_read_cycles(&user_hv_clock, guest_tsc);
+ ka->kvmclock_offset = user_clk_ns - ka->master_kernel_ns;
+
+out:
+ kvm_end_pvclock_update(kvm);
+ return rc;
+}
+#endif
+
long kvm_arch_vcpu_ioctl(struct file *filp,
unsigned int ioctl, unsigned long arg)
{
@@ -3934,6 +4099,14 @@ long kvm_arch_vcpu_ioctl(struct file *filp,
srcu_read_unlock(&vcpu->kvm->srcu, idx);
break;
}
+#ifdef CONFIG_X86_64
+ case KVM_SET_CLOCK_GUEST:
+ r = kvm_vcpu_ioctl_set_clock_guest(vcpu, argp);
+ break;
+ case KVM_GET_CLOCK_GUEST:
+ r = kvm_vcpu_ioctl_get_clock_guest(vcpu, argp);
+ break;
+#endif
#ifdef CONFIG_KVM_HYPERV
case KVM_GET_SUPPORTED_HV_CPUID:
r = kvm_ioctl_get_supported_hv_cpuid(vcpu, argp);
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 8dff2fc1972e..1349387cceb0 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1000,6 +1000,7 @@ struct kvm_enable_cap {
#define KVM_CAP_PPC_COMPAT_CAPS 250
#define KVM_CAP_ARM_PMU_V3_STRICT 251
#define KVM_CAP_GUEST_MEMFD_MEMORY_ATTRIBUTES 252
+#define KVM_CAP_CLOCK_GUEST 253
struct kvm_irq_routing_irqchip {
__u32 irqchip;
@@ -1690,4 +1691,7 @@ struct kvm_pre_fault_memory {
__u64 padding[5];
};
+#define KVM_SET_CLOCK_GUEST _IOW(KVMIO, 0xd6, struct pvclock_vcpu_time_info)
+#define KVM_GET_CLOCK_GUEST _IOR(KVMIO, 0xd7, struct pvclock_vcpu_time_info)
+
#endif /* __LINUX_KVM_H */
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v11 14/23] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate KVM clock migration
2026-11-05 15:49 ` [PATCH v11 14/23] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate KVM clock migration David Woodhouse
@ 2026-11-05 19:51 ` sashiko-bot
0 siblings, 0 replies; 33+ messages in thread
From: sashiko-bot @ 2026-11-05 19:51 UTC (permalink / raw)
To: David Woodhouse, kvm
Thank you for your contribution! Sashiko AI review found 6 potential issue(s) to consider:
- [High] KVM: x86: stale masterclock state in kvm_vcpu_ioctl_get_clock_guest()
- [High] KVM: x86: u64 underflow and overflow in kvm_vcpu_ioctl_set_clock_guest()
- [High] KVM: x86: unsigned TSC wraparound check in kvm_vcpu_ioctl_set_clock_guest()
- [High] KVM: x86: premature all_vcpus_matched_freq in kvm_track_tsc_matching()
- [Medium] KVM: x86: unreachable -EBUSY path in kvm_vcpu_ioctl_set_clock_guest()
- [Medium] KVM: x86: early return inside pvclock_sc seqcount read section in kvm_vcpu_ioctl_get_clock_guest()
--
commit a2ceb951545e5e2e7837aa6b7c533b2b547ba201
Author: Jack Allister <jalliste@amazon.com>
KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate KVM clock migration
This commit adds the per-vCPU KVM_GET_CLOCK_GUEST and KVM_SET_CLOCK_GUEST
ioctls (advertised via KVM_CAP_CLOCK_GUEST) to save and restore the
pvclock_vcpu_time_info structure in terms of the guest vCPU TSC when the VM
is using the master clock.
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 6dbdb60962fe7..bdc838b12fdc0 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
[ ... ]
> @@ -3541,6 +3544,168 @@ static int kvm_vcpu_ioctl_enable_cap(struct kvm_vcpu *vcpu,
> }
> }
>
> +#ifdef CONFIG_X86_64
> +static int kvm_vcpu_ioctl_get_clock_guest(struct kvm_vcpu *v, void __user *argp)
> +{
> + struct pvclock_vcpu_time_info hv_clock = {};
> + struct kvm_arch *ka = &v->kvm->arch;
> + unsigned int seq;
> +
> + /*
> + * Construct the pvclock purely from the master clock state. The
> + * master mul/shift are computed for the guest TSC frequency, which
> + * in master clock mode is the frequency of every vCPU; only the
> + * tsc_timestamp is per-vCPU, translating the master snapshot into
> + * this vCPU's TSC domain via its scaling ratio and offset.
> + *
> + * Note, this deliberately does NOT invoke kvm_guest_time_update(),
> + * which would write the guest's pvclock pages: dirtying guest
> + * memory after the final KVM_RUN would break post-copy migration
> + * flows. The pvclock returned here describes the same clock as the
> + * guest-visible copy (the same linear function of the guest TSC),
> + * anchored at the current master clock snapshot.
> + */
> + do {
> + seq = read_seqcount_begin(&ka->pvclock_sc);
> +
> + if (!ka->use_master_clock)
> + return -ENODATA;
[Severity: Medium]
Is it safe to return directly from inside the read_seqcount_begin() loop
when !ka->use_master_clock without calling read_seqcount_retry()?
Returning early here skips the pairing smp_rmb() and sequence validation on
ka->use_master_clock (which pvclock_update_vm_gtod_copy() updates inside
write_seqcount_begin/end and may transiently set to true before clearing it
if tsc_hz is 0), and leaves KCSAN's seqlock atomic region state active on
current because do___read_seqcount_retry() -> kcsan_atomic_next(0) is never
reached.
For comparison, kvm_guest_time_update() in arch/x86/kvm/x86.c completes the
seqcount loop before checking use_master_clock:
do {
seq = read_seqcount_begin(&ka->pvclock_sc);
use_master_clock = ka->use_master_clock;
if (!use_master_clock)
continue;
...
} while (read_seqcount_retry(&ka->pvclock_sc, seq));
> +
> + hv_clock.tsc_timestamp = kvm_read_l1_tsc(v, ka->master_cycle_now);
> + hv_clock.system_time = ka->master_kernel_ns + ka->kvmclock_offset;
> + hv_clock.tsc_shift = ka->master_tsc_shift;
> + hv_clock.tsc_to_system_mul = ka->master_tsc_mul;
> + hv_clock.flags = READ_ONCE(ka->all_vcpus_matched_tsc) ?
> + PVCLOCK_TSC_STABLE_BIT : 0;
> + } while (read_seqcount_retry(&ka->pvclock_sc, seq));
[Severity: High]
Can kvm_vcpu_ioctl_get_clock_guest() return a corrupt pvclock_vcpu_time_info
structure when KVM_REQ_MASTERCLOCK_UPDATE is pending?
Operations that change vCPU TSC frequency, TSC offset, or masterclock
eligibility — such as KVM_SET_TSC_KHZ via kvm_set_tsc_khz() ->
kvm_synchronize_tsc() -> __kvm_synchronize_tsc() -> kvm_track_tsc_matching(),
host-initiated MSR_IA32_TSC writes, KVM_VCPU_TSC_OFFSET via
kvm_arch_tsc_set_attr(), host clocksource updates via
pvclock_gtod_update_fn(), or backwards TSC detection — immediately update
v->arch.l1_tsc_scaling_ratio, v->arch.l1_tsc_offset,
ka->cur_tsc_scaling_ratio, and ka->all_vcpus_matched_freq, but defer
refreshing ka->use_master_clock, ka->master_tsc_shift, ka->master_tsc_mul,
ka->master_cycle_now, and ka->master_kernel_ns by queuing
KVM_REQ_MASTERCLOCK_UPDATE:
arch/x86/kvm/x86.c:kvm_track_tsc_matching() {
...
if ((ka->use_master_clock && update_mclock) ||
(ka->use_master_clock != use_master_clock))
kvm_make_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu);
}
Because KVM_REQ_MASTERCLOCK_UPDATE is only serviced in vcpu_enter_guest()
during KVM_RUN (and kvm_track_tsc_matching() only queues it on the single
vCPU being updated rather than VM-wide), invoking KVM_GET_CLOCK_GUEST while
vCPUs are stopped in userspace reads stale ka->use_master_clock,
ka->master_tsc_shift, and ka->master_tsc_mul while combining them with the
updated v->arch.l1_tsc_scaling_ratio and v->arch.l1_tsc_offset in
kvm_read_l1_tsc(v, ka->master_cycle_now). This either mixes a newly scaled
tsc_timestamp with old master_tsc_mul/shift (causing KVM_SET_CLOCK_GUEST to
fail with -ERANGE) or returns 0 with stale clock data instead of -ENODATA
after masterclock eligibility was lost.
[Severity: High]
Also on this read path in kvm_vcpu_ioctl_get_clock_guest(), can
ka->use_master_clock remain true even when vCPUs have mismatched TSC
frequencies?
If userspace creates vCPU 0 (online_vcpus == 1) and sets its TSC frequency
via KVM_SET_TSC_KHZ to F1 != ka->default_tsc_khz, ka->cur_tsc_khz is F1 and
ka->all_vcpus_matched_freq is true.
When vCPU 1 is subsequently created in kvm_vm_ioctl_create_vcpu(),
kvm_arch_vcpu_create() runs before atomic_inc(&kvm->online_vcpus) (while
online_vcpus is still 1) and calls kvm_set_tsc_khz(vcpu1, default_tsc_khz) ->
kvm_synchronize_tsc() -> __kvm_synchronize_tsc():
if (vcpu->arch.virtual_tsc_khz != kvm->arch.cur_tsc_khz) {
kvm->arch.cur_tsc_freq_generation++;
kvm->arch.all_vcpus_matched_freq = false;
kvm->arch.nr_vcpus_matched_freq = 0;
}
/* Count each vCPU once per freq generation */
if (vcpu->arch.this_tsc_freq_generation != kvm->arch.cur_tsc_freq_generation) {
vcpu->arch.this_tsc_freq_generation = kvm->arch.cur_tsc_freq_generation;
kvm->arch.nr_vcpus_matched_freq++;
}
kvm->arch.cur_tsc_khz = vcpu->arch.virtual_tsc_khz;
__kvm_synchronize_tsc() sees default_tsc_khz != F1, resets
nr_vcpus_matched_freq to 1, updates ka->cur_tsc_khz to default_tsc_khz, and
calls kvm_track_tsc_matching():
if (ka->all_vcpus_matched_tsc ||
ka->nr_vcpus_matched_freq >= online)
ka->all_vcpus_matched_freq = true;
Because online is still 1 during kvm_arch_vcpu_create(), 1 >= 1 is true and
ka->all_vcpus_matched_freq is latched back to true. When
kvm_arch_vcpu_postcreate() later runs after online_vcpus is incremented to 2,
vcpu1->arch.virtual_tsc_khz already matches ka->cur_tsc_khz
(default_tsc_khz), and kvm_track_tsc_matching() never clears
ka->all_vcpus_matched_freq when nr_vcpus_matched_freq < online.
As a result, ka->all_vcpus_matched_freq and ka->use_master_clock stay true
while vCPU 0 is at F1 and vCPU 1 is at default_tsc_khz, causing
kvm_vcpu_ioctl_get_clock_guest() on vCPU 0 to return a pvclock structure with
tsc_timestamp scaled for F1 and tsc_to_system_mul/tsc_shift computed for
default_tsc_khz instead of returning -ENODATA.
> +
> + if (copy_to_user(argp, &hv_clock, sizeof(hv_clock)))
> + return -EFAULT;
> +
> + return 0;
> +}
> +
> +/*
> + * Reverse the calculation in the hv_clock definition.
> + *
> + * time_ns = ( (cycles << shift) * mul ) >> 32;
> + * (although shift can be negative, so that's bad C)
> + *
> + * So for a single second,
> + * NSEC_PER_SEC = ( ( FREQ_HZ << shift) * mul ) >> 32
> + * NSEC_PER_SEC << 32 = ( FREQ_HZ << shift ) * mul
> + * ( NSEC_PER_SEC << 32 ) / mul = FREQ_HZ << shift
> + * ( NSEC_PER_SEC << 32 ) / mul ) >> shift = FREQ_HZ
> + */
> +static u64 hvclock_to_hz(u32 mul, s8 shift)
> +{
> + u64 tm = NSEC_PER_SEC << 32;
> +
> + /* Maximise precision. Shift left until the top bit is set */
> + tm <<= 2;
> + shift += 2;
> +
> + /* While 'mul' is even, increase the shift *after* the division */
> + while (!(mul & 1)) {
> + shift++;
> + mul >>= 1;
> + }
> +
> + tm /= mul;
> +
> + if (shift >= 64)
> + return 0;
> + if (shift > 0)
> + return tm >> shift;
> + if (shift <= -64)
> + return 0;
> + return tm << -shift;
> +}
> +
> +static int kvm_vcpu_ioctl_set_clock_guest(struct kvm_vcpu *v, void __user *argp)
> +{
> + struct pvclock_vcpu_time_info user_hv_clock;
> + struct kvm *kvm = v->kvm;
> + struct kvm_arch *ka = &kvm->arch;
> + u64 curr_tsc_hz, user_tsc_hz;
> + u64 user_clk_ns;
> + u64 guest_tsc;
> + int rc = 0;
> +
> + if (copy_from_user(&user_hv_clock, argp, sizeof(user_hv_clock)))
> + return -EFAULT;
> +
> + if (user_hv_clock.pad0 || user_hv_clock.pad[0] || user_hv_clock.pad[1])
> + return -EINVAL;
> +
> + if (!user_hv_clock.tsc_to_system_mul)
> + return -EINVAL;
> +
> + if (user_hv_clock.tsc_shift < -31 || user_hv_clock.tsc_shift > 31)
> + return -EINVAL;
> +
> + user_tsc_hz = hvclock_to_hz(user_hv_clock.tsc_to_system_mul,
> + user_hv_clock.tsc_shift);
> +
> + kvm_hv_request_tsc_page_update(kvm);
> +
> + /*
> + * kvm_start_pvclock_update() takes tsc_write_lock and opens
> + * the pvclock seqcount; kvm_end_pvclock_update() closes both.
> + * All clock state modifications between them are atomic with
> + * respect to readers in kvm_guest_time_update().
> + */
> + kvm_start_pvclock_update(kvm);
> + pvclock_update_vm_gtod_copy(kvm);
> +
> + if (!ka->use_master_clock) {
> + rc = -ENODATA;
> + goto out;
> + }
> +
> + curr_tsc_hz = (u64)get_cpu_tsc_khz() * HZ_PER_KHZ;
> + if (unlikely(curr_tsc_hz == 0)) {
> + rc = -EBUSY;
> + goto out;
> + }
[Severity: Medium]
Can this curr_tsc_hz == 0 (-EBUSY) branch ever be reached?
kvm_start_pvclock_update() acquires raw_spin_lock_irq(&ka->tsc_write_lock),
disabling interrupts and preemption on the local CPU. Immediately before the
!ka->use_master_clock check, pvclock_update_vm_gtod_copy() reads
get_cpu_tsc_khz() on the same CPU and clears ka->use_master_clock if tsc_hz
is 0:
arch/x86/kvm/x86.c:pvclock_update_vm_gtod_copy() {
...
tsc_hz = (u64)get_cpu_tsc_khz() * HZ_PER_KHZ;
if (tsc_hz && kvm_caps.has_tsc_control)
tsc_hz = kvm_scale_tsc(tsc_hz,
ka->master_tsc_scaling_ratio);
if (tsc_hz)
kvm_get_time_scale(NSEC_PER_SEC, tsc_hz,
&ka->master_tsc_shift,
&ka->master_tsc_mul);
else
ka->use_master_clock = false;
}
Because IRQs remain disabled across both calls, get_cpu_tsc_khz() == 0 will
always set ka->use_master_clock = false in pvclock_update_vm_gtod_copy(),
causing kvm_vcpu_ioctl_set_clock_guest() to take the !ka->use_master_clock
path and return -ENODATA rather than the documented -EBUSY.
> +
> + if (kvm_caps.has_tsc_control)
> + curr_tsc_hz = kvm_scale_tsc(curr_tsc_hz,
> + v->arch.l1_tsc_scaling_ratio);
> +
> + /*
> + * The mul/shift in the provided pvclock structure encode the guest
> + * TSC frequency at which it was generated. Sanity-check that it is
> + * consistent with this vCPU's effective TSC frequency, allowing a
> + * discrepancy of 1 kHz either way since independently calibrated
> + * hosts will not measure precisely the same value even for the
> + * same nominal frequency.
> + */
> + if (user_tsc_hz < curr_tsc_hz - 1000 ||
> + user_tsc_hz > curr_tsc_hz + 1000) {
> + rc = -ERANGE;
> + goto out;
> + }
[Severity: High]
Are there three boundary and overflow issues in the frequency calculation and
comparison between hvclock_to_hz() and kvm_vcpu_ioctl_set_clock_guest()?
First, if a vCPU's guest TSC frequency is set to 1 kHz via KVM_SET_TSC_KHZ,
set_tsc_khz() computes ratio = mul_u64_u32_div(1ULL << frac_bits, 1,
tsc_khz), which truncates down. Scaling the host TSC frequency in Hz via
kvm_scale_tsc() then yields curr_tsc_hz == 999 Hz (non-zero, so
ka->use_master_clock stays true). Because curr_tsc_hz is u64, evaluating
curr_tsc_hz - 1000 underflows to U64_MAX, making user_tsc_hz < curr_tsc_hz -
1000 unconditionally true and failing with -ERANGE.
Second, host tsc_khz is measured in whole kHz (1000 Hz steps), so a 1 kHz
calibration difference between two hosts is already 1000 Hz. Because
kvm_get_time_scale() floors tsc_to_system_mul via div_frac(), hvclock_to_hz()
rounds user_tsc_hz up by 1 to 3 Hz (for example, 2100001 kHz becomes
2100001001 Hz) while kvm_scale_tsc() can floor curr_tsc_hz by 1 Hz. Doesn't a
1 kHz host calibration difference therefore exceed +/- 1000 Hz by 1 to 3 Hz
and get rejected with -ERANGE?
Third, in hvclock_to_hz(), tm = (NSEC_PER_SEC << 34) / mul always has at
least bit 31 set (and bit 63 set when mul == 1). When shift < 0 (for example,
user_hv_clock.tsc_shift in [-31, -3]), won't tm << -shift overflow 64 bits
and wrap around modulo 2^64?
> +
> + /*
> + * Calculate the guest TSC at the new reference point, and the
> + * corresponding KVM clock value according to user_hv_clock.
> + * Adjust kvmclock_offset so both definitions agree.
> + */
> + guest_tsc = kvm_read_l1_tsc(v, ka->master_cycle_now);
> + if (guest_tsc < user_hv_clock.tsc_timestamp) {
> + rc = -EINVAL;
> + goto out;
> + }
[Severity: High]
Does the unsigned comparison guest_tsc < user_hv_clock.tsc_timestamp mishandle
64-bit modular TSC wraparound?
Guest TSC values from kvm_read_l1_tsc() and pvclock deltas in
__pvclock_read_cycles() (u64 delta = tsc - src->tsc_timestamp) use 64-bit
modular arithmetic. When a vCPU has a negative TSC offset, its guest TSC can
start near U64_MAX and wrap across 0 into small positive values as time
advances.
If user_hv_clock.tsc_timestamp was captured just before wrapping across 0
(near U64_MAX) and guest_tsc on the destination is just after 0, guest_tsc is
ahead of tsc_timestamp, but guest_tsc < user_hv_clock.tsc_timestamp evaluates
to true and rejects the call with -EINVAL. Conversely, if tsc_timestamp is a
small value just above 0 and guest_tsc is slightly behind it (wrapped below 0
to near U64_MAX), the unsigned check evaluates to false and passes a huge
delta (~U64_MAX) into __pvclock_read_cycles().
Should this check (s64)(guest_tsc - user_hv_clock.tsc_timestamp) < 0 instead?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105154955.2525419-1-dwmw2@infradead.org?part=14
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v11 15/23] KVM: selftests: Add library helpers for clock and TSC-offset ioctls
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (13 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 14/23] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate KVM clock migration David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 15:49 ` [PATCH v11 16/23] KVM: x86: Add KVM_VCPU_TSC_SCALE and fix the documentation on TSC migration David Woodhouse
` (7 subsequent siblings)
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
Add wrappers for KVM_[GS]ET_CLOCK_GUEST, the KVM_VCPU_TSC_OFFSET device
attribute and KVM_[GS]ET_CLOCK to the x86 library header, so that the
KVM clock selftests don't each open-code the same ioctl invocations.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
.../selftests/kvm/include/x86/processor.h | 50 +++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/tools/testing/selftests/kvm/include/x86/processor.h b/tools/testing/selftests/kvm/include/x86/processor.h
index 5898a277a2e0..4062bdb32716 100644
--- a/tools/testing/selftests/kvm/include/x86/processor.h
+++ b/tools/testing/selftests/kvm/include/x86/processor.h
@@ -12,6 +12,7 @@
#include <asm/msr-index.h>
#include <asm/prctl.h>
+#include <asm/pvclock-abi.h>
#include <linux/kvm_para.h>
#include <linux/stringify.h>
@@ -1029,6 +1030,55 @@ static inline void vcpu_xcrs_set(struct kvm_vcpu *vcpu, struct kvm_xcrs *xcrs)
vcpu_ioctl(vcpu, KVM_SET_XCRS, xcrs);
}
+static inline int __vcpu_get_clock_guest(struct kvm_vcpu *vcpu,
+ struct pvclock_vcpu_time_info *pvti)
+{
+ return __vcpu_ioctl(vcpu, KVM_GET_CLOCK_GUEST, pvti);
+}
+
+static inline void vcpu_get_clock_guest(struct kvm_vcpu *vcpu,
+ struct pvclock_vcpu_time_info *pvti)
+{
+ vcpu_ioctl(vcpu, KVM_GET_CLOCK_GUEST, pvti);
+}
+
+static inline int __vcpu_set_clock_guest(struct kvm_vcpu *vcpu,
+ struct pvclock_vcpu_time_info *pvti)
+{
+ return __vcpu_ioctl(vcpu, KVM_SET_CLOCK_GUEST, pvti);
+}
+
+static inline void vcpu_set_clock_guest(struct kvm_vcpu *vcpu,
+ struct pvclock_vcpu_time_info *pvti)
+{
+ vcpu_ioctl(vcpu, KVM_SET_CLOCK_GUEST, pvti);
+}
+
+static inline u64 vcpu_get_tsc_offset(struct kvm_vcpu *vcpu)
+{
+ u64 offset;
+
+ vcpu_device_attr_get(vcpu, KVM_VCPU_TSC_CTRL, KVM_VCPU_TSC_OFFSET,
+ &offset);
+ return offset;
+}
+
+static inline void vcpu_set_tsc_offset(struct kvm_vcpu *vcpu, u64 offset)
+{
+ vcpu_device_attr_set(vcpu, KVM_VCPU_TSC_CTRL, KVM_VCPU_TSC_OFFSET,
+ &offset);
+}
+
+static inline void vm_get_clock(struct kvm_vm *vm, struct kvm_clock_data *data)
+{
+ vm_ioctl(vm, KVM_GET_CLOCK, data);
+}
+
+static inline void vm_set_clock(struct kvm_vm *vm, struct kvm_clock_data *data)
+{
+ vm_ioctl(vm, KVM_SET_CLOCK, data);
+}
+
const struct kvm_cpuid_entry2 *get_cpuid_entry(const struct kvm_cpuid2 *cpuid,
u32 function, u32 index);
const struct kvm_cpuid2 *kvm_get_supported_cpuid(void);
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v11 16/23] KVM: x86: Add KVM_VCPU_TSC_SCALE and fix the documentation on TSC migration
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (14 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 15/23] KVM: selftests: Add library helpers for clock and TSC-offset ioctls David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 20:06 ` sashiko-bot
2026-11-05 15:49 ` [PATCH v11 17/23] KVM: selftests: Add KVM/PV clock selftest to prove timer correction David Woodhouse
` (6 subsequent siblings)
22 siblings, 1 reply; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
The documentation on TSC migration using KVM_VCPU_TSC_OFFSET is woefully
inadequate. It ignores TSC scaling, and ignores the fact that the host
TSC may differ from one host to the next (and in fact because of the way
the kernel calibrates it, it generally differs from one boot to the next
even on the same hardware).
Add KVM_VCPU_TSC_SCALE to extract the actual scale ratio and frac_bits,
and attempt to document the process that userspace needs to follow to
preserve the TSC across migration. Add a self test to function as an
exemplar.
Only enumerate KVM_VCPU_TSC_SCALE when kvm_caps.has_tsc_control is true,
since the scaling ratio is only meaningful when hardware TSC scaling is
supported.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Reviewed-by: Paul Durrant <paul@xen.org>
---
Documentation/virt/kvm/devices/vcpu.rst | 130 ++++-
arch/x86/include/uapi/asm/kvm.h | 6 +
arch/x86/kvm/x86.c | 21 +
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../kvm/x86/pvclock_migration_test.c | 520 ++++++++++++++++++
5 files changed, 648 insertions(+), 30 deletions(-)
create mode 100644 tools/testing/selftests/kvm/x86/pvclock_migration_test.c
diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst
index deb5c51bc00c..3daa77c5d215 100644
--- a/Documentation/virt/kvm/devices/vcpu.rst
+++ b/Documentation/virt/kvm/devices/vcpu.rst
@@ -239,6 +239,7 @@ including the layout of the stolen time structure.
:Architectures: x86
4.1 ATTRIBUTE: KVM_VCPU_TSC_OFFSET
+----------------------------------
:Parameters: 64-bit unsigned TSC offset
@@ -253,7 +254,10 @@ Returns:
Specifies the guest's TSC offset relative to the host's TSC. The guest's
TSC is then derived by the following equation:
- guest_tsc = host_tsc + KVM_VCPU_TSC_OFFSET
+ guest_tsc = ((host_tsc * tsc_ratio) >> tsc_frac_bits) + KVM_VCPU_TSC_OFFSET
+
+The values of tsc_ratio and tsc_frac_bits can be obtained using
+the KVM_VCPU_TSC_SCALE attribute.
This attribute is useful to adjust the guest's TSC on live migration,
so that the TSC counts the time during which the VM was paused. The
@@ -261,44 +265,110 @@ following describes a possible algorithm to use for this purpose.
From the source VMM process:
-1. Invoke the KVM_GET_CLOCK ioctl to record the host TSC (tsc_src),
+1. Invoke the KVM_GET_CLOCK ioctl to record the host TSC (host_tsc_src),
kvmclock nanoseconds (guest_src), and host CLOCK_REALTIME nanoseconds
- (host_src).
+ (time_src) at a given moment (Tsrc). The host_tsc field is only valid
+ when the returned flags include KVM_CLOCK_HOST_TSC.
+
+2. For each vCPU[i]:
+
+ a. Read the KVM_VCPU_TSC_OFFSET attribute to record the guest TSC offset
+ (ofs_src[i]).
+
+ b. Read the KVM_VCPU_TSC_SCALE attribute to record the guest TSC scaling
+ ratio (ratio_src[i], frac_bits_src[i]). If the attribute is not
+ supported (-ENXIO), there is no hardware TSC scaling and identity
+ scaling applies: use ratio 1, frac_bits 0.
-2. Read the KVM_VCPU_TSC_OFFSET attribute for every vCPU to record the
- guest TSC offset (ofs_src[i]).
+ c. Use host_tsc_src and the scaling/offset factors to calculate this
+ vCPU's TSC at time Tsrc:
-3. Invoke the KVM_GET_TSC_KHZ ioctl to record the frequency of the
- guest's TSC (freq).
+ tsc_src[i] = ((host_tsc_src * ratio_src[i]) >> frac_bits_src[i]) + ofs_src[i]
+
+ Note that frac_bits may be as high as 48, so this multiplication
+ needs a 128-bit intermediate to avoid overflow.
+
+3. Invoke the KVM_GET_CLOCK_GUEST ioctl on the boot vCPU to return the KVM
+ clock as a function of the guest TSC (pvti_src). (This ioctl may not
+ succeed if the host and guest TSCs are not consistent and well-behaved.)
From the destination VMM process:
-4. Invoke the KVM_SET_CLOCK ioctl, providing the source nanoseconds from
- kvmclock (guest_src) and CLOCK_REALTIME (host_src) in their respective
- fields. Ensure that the KVM_CLOCK_REALTIME flag is set in the provided
- structure.
+4. Invoke the KVM_SET_TSC_KHZ ioctl to set the scaled frequency of the
+ guest's TSC (freq) — either on the VM before creating the vCPUs, or
+ on each vCPU after creating it (as the exemplar test does).
+
+5. Invoke the KVM_GET_CLOCK ioctl to record the host TSC (host_tsc_dst) and
+ host CLOCK_REALTIME nanoseconds (time_dst) at a given moment (Tdst),
+ again checking KVM_CLOCK_HOST_TSC in the returned flags.
+
+6. Calculate the number of nanoseconds elapsed between Tsrc and Tdst:
+
+ ΔT = time_dst - time_src
+
+7. As each vCPU[i] is created:
+
+ a. Read the KVM_VCPU_TSC_SCALE attribute to record the guest TSC scaling
+ ratio (ratio_dst[i], frac_bits_dst[i]).
+
+ b. Calculate the intended guest TSC value at time Tdst, taking care
+ with the units (ΔT is in nanoseconds; freq, as set by
+ KVM_SET_TSC_KHZ, is in kHz):
+
+ tsc_dst[i] = tsc_src[i] + (ΔT * freq[i] / 10^6)
- KVM will advance the VM's kvmclock to account for elapsed time since
- recording the clock values. Note that this will cause problems in
- the guest (e.g., timeouts) unless CLOCK_REALTIME is synchronized
- between the source and destination, and a reasonably short time passes
- between the source pausing the VMs and the destination executing
- steps 4-7.
+ c. Use host_tsc_dst and the scaling factors to calculate this vCPU's
+ raw scaled TSC at time Tdst without offsetting:
+
+ raw_dst[i] = ((host_tsc_dst * ratio_dst[i]) >> frac_bits_dst[i])
+
+ d. Calculate ofs_dst[i] = tsc_dst[i] - raw_dst[i] and set the resulting
+ offset using the KVM_VCPU_TSC_OFFSET attribute.
+
+8. If pvti_src was provided, invoke the KVM_SET_CLOCK_GUEST ioctl on the boot
+ vCPU to restore the KVM clock as a precise function of the guest TSC.
+
+9. If KVM_SET_CLOCK_GUEST was not available or failed (e.g. because the
+ master clock is not active), fall back to the KVM_SET_CLOCK ioctl,
+ providing the source nanoseconds from kvmclock (guest_src) and
+ CLOCK_REALTIME (time_src) in their respective fields. Ensure that the
+ KVM_CLOCK_REALTIME flag is set in the provided structure.
+
+ KVM will restore the VM's kvmclock, accounting for elapsed time since
+ the clock values were recorded. Note that this will cause problems in
+ the guest (e.g., timeouts) unless CLOCK_REALTIME is synchronized between
+ the source and destination, and a reasonably short time passes between
+ the source pausing the VMs and the destination resuming them.
+ Due to the KVM_[SG]ET_CLOCK API using CLOCK_REALTIME instead of
+ CLOCK_TAI, leap seconds during the migration may also introduce errors.
+
+4.2 ATTRIBUTE: KVM_VCPU_TSC_SCALE
+---------------------------------
+
+:Parameters: struct kvm_vcpu_tsc_scale
+
+Returns:
+
+ ======= ======================================
+ -EFAULT Error writing the result to the
+ provided address.
+ -ENXIO Attribute not supported (no TSC scaling)
+ -EINVAL Invalid request to write the attribute
+ ======= ======================================
-5. Invoke the KVM_GET_CLOCK ioctl to record the host TSC (tsc_dest) and
- kvmclock nanoseconds (guest_dest).
+This read-only attribute reports the guest's TSC scaling factor, in the form
+of a fixed-point number represented by the following structure::
-6. Adjust the guest TSC offsets for every vCPU to account for (1) time
- elapsed since recording state and (2) difference in TSCs between the
- source and destination machine:
+ struct kvm_vcpu_tsc_scale {
+ __u64 tsc_ratio;
+ __u64 tsc_frac_bits;
+ };
- ofs_dst[i] = ofs_src[i] -
- (guest_src - guest_dest) * freq +
- (tsc_src - tsc_dest)
+The tsc_frac_bits field indicates the location of the fixed point, such that
+host TSC values are converted to guest TSC using the formula:
- ("ofs[i] + tsc - guest * freq" is the guest TSC value corresponding to
- a time of 0 in kvmclock. The above formula ensures that it is the
- same on the destination as it was on the source).
+ guest_tsc = ((host_tsc * tsc_ratio) >> tsc_frac_bits) + offset
-7. Write the KVM_VCPU_TSC_OFFSET attribute for every vCPU with the
- respective value derived in the previous step.
+Userspace can use this to precisely calculate the guest TSC from the host
+TSC at any given moment. This is needed for accurate migration of guests,
+as described in the documentation for the KVM_VCPU_TSC_OFFSET attribute.
diff --git a/arch/x86/include/uapi/asm/kvm.h b/arch/x86/include/uapi/asm/kvm.h
index 9e3cdc3adb65..f8274d8e471d 100644
--- a/arch/x86/include/uapi/asm/kvm.h
+++ b/arch/x86/include/uapi/asm/kvm.h
@@ -964,6 +964,12 @@ struct kvm_hyperv_eventfd {
/* for KVM_{GET,SET,HAS}_DEVICE_ATTR */
#define KVM_VCPU_TSC_CTRL 0 /* control group for the timestamp counter (TSC) */
#define KVM_VCPU_TSC_OFFSET 0 /* attribute for the TSC offset */
+#define KVM_VCPU_TSC_SCALE 1 /* attribute for TSC scaling factor */
+
+struct kvm_vcpu_tsc_scale {
+ __u64 tsc_ratio;
+ __u64 tsc_frac_bits;
+};
/* x86-specific KVM_EXIT_HYPERCALL flags. */
#define KVM_EXIT_HYPERCALL_LONG_MODE _BITULL(0)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index bdc838b12fdc..17544b3cc035 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3396,6 +3396,9 @@ static int kvm_arch_tsc_has_attr(struct kvm_vcpu *vcpu,
case KVM_VCPU_TSC_OFFSET:
r = 0;
break;
+ case KVM_VCPU_TSC_SCALE:
+ r = kvm_caps.has_tsc_control ? 0 : -ENXIO;
+ break;
default:
r = -ENXIO;
}
@@ -3416,6 +3419,21 @@ static int kvm_arch_tsc_get_attr(struct kvm_vcpu *vcpu,
break;
r = 0;
break;
+ case KVM_VCPU_TSC_SCALE: {
+ struct kvm_vcpu_tsc_scale scale;
+
+ r = -ENXIO;
+ if (!kvm_caps.has_tsc_control)
+ break;
+
+ scale.tsc_ratio = vcpu->arch.l1_tsc_scaling_ratio;
+ scale.tsc_frac_bits = kvm_caps.tsc_scaling_ratio_frac_bits;
+ r = -EFAULT;
+ if (copy_to_user(uaddr, &scale, sizeof(scale)))
+ break;
+ r = 0;
+ break;
+ }
default:
r = -ENXIO;
}
@@ -3455,6 +3473,9 @@ static int kvm_arch_tsc_set_attr(struct kvm_vcpu *vcpu,
r = 0;
break;
}
+ case KVM_VCPU_TSC_SCALE:
+ r = kvm_caps.has_tsc_control ? -EINVAL : -ENXIO;
+ break;
default:
r = -ENXIO;
}
diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index 888a7530a280..18605318860e 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -113,6 +113,7 @@ TEST_GEN_PROGS_x86 += x86/pmu_counters_test
TEST_GEN_PROGS_x86 += x86/pmu_event_filter_test
TEST_GEN_PROGS_x86 += x86/private_mem_conversions_test
TEST_GEN_PROGS_x86 += x86/private_mem_kvm_exits_test
+TEST_GEN_PROGS_x86 += x86/pvclock_migration_test
TEST_GEN_PROGS_x86 += x86/save_restore_pf_stress_test
TEST_GEN_PROGS_x86 += x86/set_boot_cpu_id
TEST_GEN_PROGS_x86 += x86/set_sregs_test
diff --git a/tools/testing/selftests/kvm/x86/pvclock_migration_test.c b/tools/testing/selftests/kvm/x86/pvclock_migration_test.c
new file mode 100644
index 000000000000..c4a64b6a2e42
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86/pvclock_migration_test.c
@@ -0,0 +1,520 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Test KVM clock precision across simulated live migration.
+ *
+ * Verifies that the documented TSC migration procedure (using
+ * KVM_VCPU_TSC_OFFSET, KVM_VCPU_TSC_SCALE, KVM_GET_CLOCK, and
+ * KVM_SET_CLOCK_GUEST) preserves the kvmclock's relationship to
+ * CLOCK_MONOTONIC_RAW — including for vCPUs whose TSCs are offset
+ * from one another (same frequency), which no longer disables the
+ * master clock.
+ *
+ * The test:
+ * 1. Creates a VM with 3 vCPUs, runs each guest to enable kvmclock
+ * 2. Applies divergent TSC offsets to vCPUs 1 and 2
+ * 3. Verifies the master clock remains active (KVM_CLOCK_HOST_TSC),
+ * that the guests see PVCLOCK_TSC_STABLE_BIT clear, and that all
+ * vCPUs' pvclocks agree on "now" despite the divergent offsets
+ * 4. Does a PTP-like ABA measurement of kvmclock vs CLOCK_MONOTONIC_RAW
+ * 5. Follows the documented migration procedure (same host, 1s pause),
+ * migrating each vCPU's TSC individually but setting the KVM clock
+ * only once, via KVM_SET_CLOCK_GUEST on vCPU0
+ * 6. Does the same ABA measurement on the destination VM
+ * 7. Verifies the kvmclock-vs-monotonic delta is preserved, the
+ * cross-vCPU TSC deltas are preserved, and all destination vCPUs'
+ * pvclocks again agree on "now"
+ */
+#include <inttypes.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <string.h>
+#include <time.h>
+#include <unistd.h>
+
+#include "test_util.h"
+#include "kvm_util.h"
+#include "processor.h"
+
+#include <asm/pvclock-abi.h>
+
+#define KVMCLOCK_GPA 0xc0000000ULL
+#define NR_VCPUS 3
+
+/*
+ * Divergent TSC offsets applied to vCPUs 1 and 2, in guest cycles.
+ * Roughly +1s and -0.5s at 1.5 GHz — large enough that any failure
+ * to account for them is orders of magnitude outside the ABA bounds.
+ */
+static const s64 tsc_deltas[NR_VCPUS] = { 0, 1500000000LL, -750000000LL };
+
+static void guest_code(int idx)
+{
+ wrmsr(MSR_KVM_SYSTEM_TIME_NEW, (KVMCLOCK_GPA + idx * PAGE_SIZE) | 1);
+
+ for (;;)
+ GUEST_SYNC(0);
+}
+
+static u64 read_kvmclock_ns(struct kvm_vm *vm)
+{
+ struct kvm_clock_data data = {};
+
+ vm_get_clock(vm, &data);
+ return data.clock;
+}
+
+static u64 pvclock_read_cycles(struct pvclock_vcpu_time_info *src,
+ u64 tsc)
+{
+ u64 delta = tsc - src->tsc_timestamp;
+ u64 ns;
+
+ if (src->tsc_shift >= 0)
+ delta <<= src->tsc_shift;
+ else
+ delta >>= -(s32)src->tsc_shift;
+
+ ns = (unsigned __int128)delta * src->tsc_to_system_mul >> 32;
+ return src->system_time + ns;
+}
+
+/*
+ * ABA measurement: read CLOCK_MONOTONIC_RAW, kvmclock, CLOCK_MONOTONIC_RAW.
+ * Repeat 3 times, keep the reading with the smallest spread.
+ */
+static void aba_reading(struct kvm_vm *vm, u64 *lo, u64 *kvm_ns,
+ u64 *hi)
+{
+ u64 best_spread = UINT64_MAX;
+ int i;
+
+ for (i = 0; i < 3; i++) {
+ struct timespec ts1, ts2;
+ u64 m1, m2, clk;
+
+ clock_gettime(CLOCK_MONOTONIC_RAW, &ts1);
+ clk = read_kvmclock_ns(vm);
+ clock_gettime(CLOCK_MONOTONIC_RAW, &ts2);
+
+ m1 = ts1.tv_sec * 1000000000ULL + ts1.tv_nsec;
+ m2 = ts2.tv_sec * 1000000000ULL + ts2.tv_nsec;
+
+ if (m2 - m1 < best_spread) {
+ best_spread = m2 - m1;
+ *lo = m1;
+ *kvm_ns = clk;
+ *hi = m2;
+ }
+ }
+}
+
+static struct kvm_vm *create_vm(struct kvm_vcpu **vcpus, u32 freq_khz)
+{
+ struct kvm_vm *vm;
+ int i;
+
+ vm = vm_create_with_vcpus(NR_VCPUS, guest_code, vcpus);
+
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS,
+ KVMCLOCK_GPA, 1, NR_VCPUS, 0);
+ virt_map(vm, KVMCLOCK_GPA, KVMCLOCK_GPA, NR_VCPUS);
+
+ for (i = 0; i < NR_VCPUS; i++) {
+ vcpu_args_set(vcpus[i], 1, i);
+ /* Set guest TSC frequency (may trigger scaling) */
+ vcpu_ioctl(vcpus[i], KVM_SET_TSC_KHZ,
+ (void *)(unsigned long)freq_khz);
+ }
+ return vm;
+}
+
+static void run_to_sync(struct kvm_vcpu *vcpu)
+{
+ struct ucall uc;
+
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
+ TEST_ASSERT_EQ(get_ucall(vcpu, &uc), UCALL_SYNC);
+}
+
+/*
+ * Compute a vCPU's guest TSC for a given host TSC value, using the
+ * vCPU's scale and offset as saved from KVM_VCPU_TSC_SCALE/OFFSET.
+ */
+static u64 host_to_guest_tsc(struct kvm_vcpu_tsc_scale *scale, u64 ofs,
+ u64 host_tsc)
+{
+ if (scale->tsc_frac_bits)
+ return ((unsigned __int128)host_tsc * scale->tsc_ratio
+ >> scale->tsc_frac_bits) + ofs;
+ return host_tsc + ofs;
+}
+
+/*
+ * Verify that all vCPUs agree on the KVM clock, despite having
+ * different TSC offsets. Take one atomic {host_tsc, kvmclock} pair
+ * for the whole VM, derive each vCPU's guest TSC at that instant,
+ * and evaluate each vCPU's pvti at its own guest TSC. All must give
+ * the same nanosecond value (same instant, same clock), and must
+ * match what KVM_GET_CLOCK itself said.
+ */
+static void check_cross_vcpu_coherence(struct kvm_vm *vm,
+ struct kvm_vcpu **vcpus,
+ struct pvclock_vcpu_time_info *pvtis,
+ const char *what)
+{
+ struct kvm_clock_data now = {};
+ u64 clk[NR_VCPUS];
+ int i;
+
+ vm_get_clock(vm, &now);
+ TEST_ASSERT(now.flags & KVM_CLOCK_HOST_TSC,
+ "%s: master clock inactive with divergent TSC offsets",
+ what);
+
+ for (i = 0; i < NR_VCPUS; i++) {
+ struct kvm_vcpu_tsc_scale scale = {};
+ u64 ofs = vcpu_get_tsc_offset(vcpus[i]);
+ u64 guest_tsc;
+
+ vcpu_device_attr_get(vcpus[i], KVM_VCPU_TSC_CTRL,
+ KVM_VCPU_TSC_SCALE, &scale);
+ guest_tsc = host_to_guest_tsc(&scale, ofs, now.host_tsc);
+ clk[i] = pvclock_read_cycles(&pvtis[i], guest_tsc);
+
+ TEST_ASSERT(!(pvtis[i].flags & PVCLOCK_TSC_STABLE_BIT),
+ "%s: vCPU%d still advertises TSC_STABLE with divergent offsets",
+ what, i);
+ }
+
+ for (i = 1; i < NR_VCPUS; i++) {
+ s64 d = (s64)(clk[i] - clk[0]);
+
+ pr_info(" %s: vCPU%d vs vCPU0 kvmclock delta %" PRId64 " ns\n",
+ what, i, d);
+ TEST_ASSERT(d >= -2 && d <= 2,
+ "%s: vCPU%d kvmclock disagrees with vCPU0 by %" PRId64 " ns",
+ what, i, d);
+ }
+
+ /* And all of them must agree with KVM_GET_CLOCK itself */
+ s64 d0 = (s64)(clk[0] - now.clock);
+ pr_info(" %s: vCPU0 pvclock vs KVM_GET_CLOCK delta %" PRId64 " ns\n",
+ what, d0);
+ TEST_ASSERT(d0 >= -2 && d0 <= 2,
+ "%s: vCPU0 pvclock disagrees with KVM_GET_CLOCK by %" PRId64 " ns",
+ what, d0);
+}
+
+int main(void)
+{
+ struct pvclock_vcpu_time_info pvti_src[NR_VCPUS];
+ struct pvclock_vcpu_time_info pvti_dst_ioctl[NR_VCPUS];
+ struct kvm_clock_data clock_src, clock_dst;
+ struct kvm_vcpu_tsc_scale scale_src[NR_VCPUS], scale_dst;
+ struct kvm_vcpu *vcpus[NR_VCPUS];
+ struct kvm_vm *vm;
+ u64 mono_before, kvm_before, kvm_after;
+ s64 delta_before;
+ u64 ofs_src[NR_VCPUS], tsc_src[NR_VCPUS], tsc_dst, raw_dst;
+ u64 ofs_dst[NR_VCPUS];
+ u64 host_tsc_src, host_tsc_dst;
+ u64 time_src, time_dst;
+ s64 delta_t;
+ u32 freq_khz = 1500000; /* 1.5 GHz — forces TSC scaling */
+ int i, pass;
+
+ TEST_REQUIRE(sys_clocksource_is_based_on_tsc());
+ TEST_REQUIRE(kvm_has_cap(KVM_CAP_TSC_CONTROL));
+
+ /* === SOURCE SIDE === */
+ pr_info("=== Source VM ===\n");
+ vm = create_vm(vcpus, freq_khz);
+
+ /* Run each guest to enable its kvmclock */
+ for (i = 0; i < NR_VCPUS; i++)
+ run_to_sync(vcpus[i]);
+
+ /*
+ * Apply divergent TSC offsets. Same frequency, different offsets:
+ * this must no longer disable the master clock, but must clear
+ * PVCLOCK_TSC_STABLE_BIT.
+ */
+ for (i = 1; i < NR_VCPUS; i++)
+ vcpu_set_tsc_offset(vcpus[i],
+ vcpu_get_tsc_offset(vcpus[i]) + tsc_deltas[i]);
+
+ /*
+ * Re-run each vCPU twice. The offset writes leave a masterclock
+ * update pending on vCPUs 1 and 2; the first pass processes it and
+ * broadcasts KVM_REQ_CLOCK_UPDATE to every vCPU, and the second
+ * pass has each vCPU rewrite its guest-visible pvclock page with
+ * PVCLOCK_TSC_STABLE_BIT now clear. A single pass would leave
+ * vCPU0's page stale: its rewrite happens before the broadcast.
+ */
+ for (pass = 0; pass < 2; pass++)
+ for (i = 0; i < NR_VCPUS; i++)
+ run_to_sync(vcpus[i]);
+
+ /* Fetch each vCPU's pvti and verify cross-vCPU coherence */
+ for (i = 0; i < NR_VCPUS; i++)
+ vcpu_get_clock_guest(vcpus[i], &pvti_src[i]);
+ check_cross_vcpu_coherence(vm, vcpus, pvti_src, "source");
+
+ /* The guest-visible pvti pages must also show TSC_STABLE clear */
+ for (i = 0; i < NR_VCPUS; i++) {
+ struct pvclock_vcpu_time_info *pvti =
+ addr_gpa2hva(vm, KVMCLOCK_GPA + i * getpagesize());
+
+ TEST_ASSERT(!(pvti->flags & PVCLOCK_TSC_STABLE_BIT),
+ "vCPU%d guest pvti advertises TSC_STABLE with divergent offsets", i);
+ }
+
+ /* ABA measurement: kvmclock vs CLOCK_MONOTONIC_RAW */
+ u64 src_mono_lo, src_mono_hi;
+ aba_reading(vm, &src_mono_lo, &kvm_before, &src_mono_hi);
+ mono_before = (src_mono_lo + src_mono_hi) / 2;
+ delta_before = (s64)(kvm_before - mono_before);
+ pr_info(" kvmclock - MONOTONIC_RAW = %" PRId64 " ns (±%" PRIu64 " ns)\n",
+ delta_before, (src_mono_hi - src_mono_lo) / 2);
+
+ /* Step 1: KVM_GET_CLOCK for atomic {host_tsc, realtime} */
+ memset(&clock_src, 0, sizeof(clock_src));
+ clock_src.flags = KVM_CLOCK_REALTIME;
+ vm_get_clock(vm, &clock_src);
+ TEST_ASSERT(clock_src.flags & KVM_CLOCK_HOST_TSC,
+ "KVM_GET_CLOCK did not provide host_tsc (no master clock?)");
+ host_tsc_src = clock_src.host_tsc;
+ time_src = clock_src.realtime;
+
+ /* Step 2: Save each vCPU's TSC offset and scale */
+ for (i = 0; i < NR_VCPUS; i++) {
+ ofs_src[i] = vcpu_get_tsc_offset(vcpus[i]);
+ memset(&scale_src[i], 0, sizeof(scale_src[i]));
+ vcpu_device_attr_get(vcpus[i], KVM_VCPU_TSC_CTRL,
+ KVM_VCPU_TSC_SCALE, &scale_src[i]);
+
+ /* Compute this vCPU's guest TSC at Tsrc */
+ tsc_src[i] = host_to_guest_tsc(&scale_src[i], ofs_src[i],
+ host_tsc_src);
+ pr_info(" vCPU%d: TSC freq=%u kHz, offset=%" PRId64 "\n",
+ i, freq_khz, (s64)ofs_src[i]);
+ }
+
+ /* Step 3: KVM_GET_CLOCK_GUEST (already fetched above as pvti_src[]) */
+
+ kvm_vm_release(vm);
+
+ /* === PAUSE (simulate migration) === */
+ pr_info("=== Pausing 1 second ===\n");
+ sleep(1);
+
+ /* === DESTINATION SIDE === */
+ pr_info("=== Destination VM ===\n");
+ /* Step 4: create + KVM_SET_TSC_KHZ (in create_vm) */
+ vm = create_vm(vcpus, freq_khz);
+
+ /* Step 5: KVM_GET_CLOCK for atomic {host_tsc, realtime} pair.
+ * Master clock is active from VM creation.
+ */
+ memset(&clock_dst, 0, sizeof(clock_dst));
+ vm_get_clock(vm, &clock_dst);
+ TEST_ASSERT(clock_dst.flags & KVM_CLOCK_HOST_TSC,
+ "KVM_GET_CLOCK did not provide host_tsc (no master clock?)");
+ host_tsc_dst = clock_dst.host_tsc;
+ time_dst = clock_dst.realtime;
+
+ /* Step 6: ΔT */
+ delta_t = (s64)(time_dst - time_src);
+
+ /* Step 7: Compute and set each vCPU's destination offset */
+ memset(&scale_dst, 0, sizeof(scale_dst));
+ vcpu_device_attr_get(vcpus[0], KVM_VCPU_TSC_CTRL, KVM_VCPU_TSC_SCALE,
+ &scale_dst);
+
+ if (scale_dst.tsc_frac_bits)
+ raw_dst = (unsigned __int128)host_tsc_dst * scale_dst.tsc_ratio
+ >> scale_dst.tsc_frac_bits;
+ else
+ raw_dst = host_tsc_dst;
+
+ for (i = 0; i < NR_VCPUS; i++) {
+ tsc_dst = tsc_src[i] + (u64)((s64)freq_khz * delta_t / 1000000LL);
+ ofs_dst[i] = tsc_dst - raw_dst;
+ vcpu_set_tsc_offset(vcpus[i], ofs_dst[i]);
+ }
+
+ /*
+ * The cross-vCPU TSC relationships must be preserved exactly:
+ * every vCPU's offset moved by the same amount, so the deltas
+ * between them are untouched by the CLOCK_REALTIME imprecision.
+ */
+ for (i = 1; i < NR_VCPUS; i++) {
+ s64 src_delta = (s64)(ofs_src[i] - ofs_src[0]);
+ s64 dst_delta = (s64)(ofs_dst[i] - ofs_dst[0]);
+
+ pr_info(" vCPU%d-vCPU0 TSC delta: src %" PRId64
+ ", dst %" PRId64 " cycles\n", i, src_delta, dst_delta);
+ TEST_ASSERT(src_delta == dst_delta,
+ "vCPU%d TSC delta not preserved: %" PRId64 " -> %" PRId64,
+ i, src_delta, dst_delta);
+ }
+
+ /*
+ * The TSC offset delta introduced by using CLOCK_REALTIME to
+ * estimate elapsed time. On same host, the correct offset is
+ * ofs_src; the difference is the CLOCK_REALTIME-vs-TSC error.
+ */
+ s64 tsc_ofs_delta = (s64)(ofs_dst[0] - ofs_src[0]);
+ s64 tsc_ofs_delta_ns = tsc_ofs_delta * 1000000LL / freq_khz;
+ pr_info(" Destination TSC offset=%" PRId64
+ ", imprecision from CLOCK_REALTIME: %" PRId64 " cycles = %"
+ PRId64 " ns\n", (s64)ofs_dst[0], tsc_ofs_delta, tsc_ofs_delta_ns);
+
+ /*
+ * Step 8: KVM_SET_CLOCK_GUEST — once, via vCPU0. The other
+ * vCPUs' clocks must come out right too: the KVM clock is
+ * VM-wide, and each vCPU's pvti relates it to that vCPU's
+ * own TSC.
+ */
+ vcpu_set_clock_guest(vcpus[0], &pvti_src[0]);
+
+ /* Run each guest to write its pvclock page on the destination */
+ for (i = 0; i < NR_VCPUS; i++)
+ run_to_sync(vcpus[i]);
+
+ /* Verify cross-vCPU coherence on the destination */
+ for (i = 0; i < NR_VCPUS; i++)
+ vcpu_get_clock_guest(vcpus[i], &pvti_dst_ioctl[i]);
+ check_cross_vcpu_coherence(vm, vcpus, pvti_dst_ioctl, "dest");
+
+ /* ABA measurement on destination */
+ u64 mono_lo, mono_hi;
+ aba_reading(vm, &mono_lo, &kvm_after, &mono_hi);
+
+ /*
+ * The kvmclock is tied to the guest TSC via SET_CLOCK_GUEST.
+ * The guest TSC is offset from the correct value by tsc_ofs_delta_ns
+ * (due to CLOCK_REALTIME imprecision). So the kvmclock should be
+ * offset from CLOCK_MONOTONIC_RAW by exactly:
+ * (original delta) + tsc_ofs_delta_ns
+ *
+ * The "original delta" has uncertainty from the source ABA spread,
+ * and the measurement has uncertainty from the destination ABA spread.
+ * Verify the expected value falls within the combined bounds.
+ */
+ s64 delta_before_lo = (s64)(kvm_before - src_mono_hi);
+ s64 delta_before_hi = (s64)(kvm_before - src_mono_lo);
+ s64 expected_lo = delta_before_lo + tsc_ofs_delta_ns;
+ s64 expected_hi = delta_before_hi + tsc_ofs_delta_ns;
+ s64 actual_lo = (s64)(kvm_after - mono_hi);
+ s64 actual_hi = (s64)(kvm_after - mono_lo);
+
+ /* Show the shift relative to the source measurement */
+ s64 expected_mid = tsc_ofs_delta_ns;
+ s64 expected_err = (s64)(src_mono_hi - src_mono_lo) / 2;
+ s64 actual_mid = ((actual_lo + actual_hi) / 2) - delta_before;
+ s64 actual_err = (s64)(mono_hi - mono_lo) / 2;
+ pr_info(" kvmclock-mono shift: expected %" PRId64 " ns (±%" PRId64
+ "), measured %" PRId64 " ns (±%" PRId64 ")\n",
+ expected_mid, expected_err, actual_mid, actual_err);
+
+ /* The ranges must overlap */
+ TEST_ASSERT(expected_hi >= actual_lo && expected_lo <= actual_hi,
+ "Ranges don't overlap: expected [%" PRId64 ", %" PRId64
+ "] measured [%" PRId64 ", %" PRId64 "]",
+ expected_lo, expected_hi, actual_lo, actual_hi);
+
+ /*
+ * Direct pvclock verification: read each destination pvclock page
+ * (as written for the guest) and verify that computing kvmclock
+ * from the source pvti and the destination pvti at the same
+ * instant gives the same result, for every vCPU.
+ *
+ * Get one atomic {host_tsc, kvmclock} pair, derive each vCPU's
+ * guest TSC at that instant, then compute kvmclock from both
+ * pvclock structs. The source pvti evaluates at the *migrated*
+ * guest TSC, i.e. shifted by the CLOCK_REALTIME imprecision that
+ * was baked into the offsets — which is exactly what "the clock
+ * follows the TSC" means.
+ */
+ struct kvm_clock_data clock_now = {};
+ vm_get_clock(vm, &clock_now);
+ pr_info(" KVM_GET_CLOCK: %" PRIu64 " ns\n", (u64)clock_now.clock);
+
+ u64 host_tsc_now = clock_now.host_tsc;
+
+ for (i = 0; i < NR_VCPUS; i++) {
+ struct pvclock_vcpu_time_info *pvti_page =
+ addr_gpa2hva(vm, KVMCLOCK_GPA + i * getpagesize());
+ u64 guest_tsc_now = host_to_guest_tsc(&scale_dst, ofs_dst[i],
+ host_tsc_now);
+ u64 clk_from_src = pvclock_read_cycles(&pvti_src[i],
+ guest_tsc_now);
+ u64 clk_from_dst = pvclock_read_cycles(pvti_page,
+ guest_tsc_now);
+ s64 pvclock_delta = (s64)(clk_from_src - clk_from_dst);
+
+ pr_info(" vCPU%d pvclock direct: src=%" PRIu64 " dst=%" PRIu64
+ " delta=%" PRId64 " ns\n", i, clk_from_src,
+ clk_from_dst, pvclock_delta);
+
+ TEST_ASSERT(pvclock_delta >= -2 && pvclock_delta <= 2,
+ "vCPU%d pvclock src vs dst disagree by %" PRId64 " ns",
+ i, pvclock_delta);
+ }
+
+ /*
+ * Tight ABA: compare pvclock_read() directly (no ioctl) against
+ * CLOCK_MONOTONIC_RAW. The spread should be much smaller since
+ * there's no syscall between the two clock_gettime calls — just
+ * rdtsc + userspace mul/shift.
+ */
+ struct pvclock_vcpu_time_info *pvti0 = addr_gpa2hva(vm, KVMCLOCK_GPA);
+ u64 tight_mono_lo = 0, tight_mono_hi = 0, tight_kvm = 0;
+ u64 tight_best_spread = UINT64_MAX;
+ for (i = 0; i < 3; i++) {
+ struct timespec ts1, ts2;
+ u64 m1, m2, tsc, clk;
+
+ clock_gettime(CLOCK_MONOTONIC_RAW, &ts1);
+ tsc = rdtsc();
+ clock_gettime(CLOCK_MONOTONIC_RAW, &ts2);
+
+ m1 = ts1.tv_sec * 1000000000ULL + ts1.tv_nsec;
+ m2 = ts2.tv_sec * 1000000000ULL + ts2.tv_nsec;
+
+ /* Scale host TSC to vCPU0's guest TSC */
+ tsc = host_to_guest_tsc(&scale_dst, ofs_dst[0], tsc);
+
+ clk = pvclock_read_cycles(pvti0, tsc);
+
+ if (m2 - m1 < tight_best_spread) {
+ tight_best_spread = m2 - m1;
+ tight_mono_lo = m1;
+ tight_mono_hi = m2;
+ tight_kvm = clk;
+ }
+ }
+ pr_info(" Tight ABA spread: %" PRIu64 " ns (best of 3)\n", tight_best_spread);
+
+ s64 tight_expected_lo = delta_before_lo + tsc_ofs_delta_ns;
+ s64 tight_expected_hi = delta_before_hi + tsc_ofs_delta_ns;
+ s64 tight_actual_lo = (s64)(tight_kvm - tight_mono_hi);
+ s64 tight_actual_hi = (s64)(tight_kvm - tight_mono_lo);
+ s64 tight_actual_mid = ((tight_actual_lo + tight_actual_hi) / 2) - delta_before;
+ s64 tight_actual_err = (s64)(tight_mono_hi - tight_mono_lo) / 2;
+
+ pr_info(" Tight kvmclock-mono shift: expected %" PRId64
+ " ns (±%" PRId64 "), measured %" PRId64 " ns (±%" PRId64 ")\n",
+ expected_mid, expected_err, tight_actual_mid, tight_actual_err);
+
+ TEST_ASSERT(tight_expected_hi >= tight_actual_lo &&
+ tight_expected_lo <= tight_actual_hi,
+ "Tight ABA ranges don't overlap");
+
+ kvm_vm_release(vm);
+ pr_info("PASS: kvmclock offset matches TSC delta from CLOCK_REALTIME"
+ " (%" PRId64 " ns) within ABA bounds\n", tsc_ofs_delta_ns);
+ return 0;
+}
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v11 16/23] KVM: x86: Add KVM_VCPU_TSC_SCALE and fix the documentation on TSC migration
2026-11-05 15:49 ` [PATCH v11 16/23] KVM: x86: Add KVM_VCPU_TSC_SCALE and fix the documentation on TSC migration David Woodhouse
@ 2026-11-05 20:06 ` sashiko-bot
0 siblings, 0 replies; 33+ messages in thread
From: sashiko-bot @ 2026-11-05 20:06 UTC (permalink / raw)
To: David Woodhouse, kvm
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [Medium] KVM: selftests: missing TEST_REQUIRE() checks in pvclock_migration_test
- [Low] KVM: x86: doc per-vCPU KVM_SET_TSC_KHZ order breaks KVM_SET_CLOCK_GUEST
- [Low] KVM: x86: vcpu.rst drops source KVM_GET_TSC_KHZ step still used on dest
- [Low] KVM: selftests: VM memory leak in main() from using kvm_vm_release()
- [Low] KVM: selftests: duplicated pvclock and TSC scaling helpers in test
--
commit 17f0fed5469017ce773a7df8f640aab41b731a06
Author: David Woodhouse <dwmw@amazon.co.uk>
KVM: x86: Add KVM_VCPU_TSC_SCALE and fix the documentation on TSC migration
This commit adds the KVM_VCPU_TSC_SCALE device attribute to expose a vCPU's
TSC scaling ratio and fraction bits to userspace when hardware TSC scaling is
supported. It also updates the vCPU TSC migration documentation and adds a
selftest to verify kvmclock precision across simulated live migration.
> diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst
> index deb5c51bc00c8..3daa77c5d2150 100644
> --- a/Documentation/virt/kvm/devices/vcpu.rst
> +++ b/Documentation/virt/kvm/devices/vcpu.rst
> @@ -239,6 +239,7 @@ including the layout of the stolen time structure.
> :Architectures: x86
>
> 4.1 ATTRIBUTE: KVM_VCPU_TSC_OFFSET
> +----------------------------------
[ ... ]
> @@ -261,44 +265,110 @@ following describes a possible algorithm to use for this purpose.
>
> From the source VMM process:
>
> -1. Invoke the KVM_GET_CLOCK ioctl to record the host TSC (tsc_src),
> +1. Invoke the KVM_GET_CLOCK ioctl to record the host TSC (host_tsc_src),
> kvmclock nanoseconds (guest_src), and host CLOCK_REALTIME nanoseconds
> - (host_src).
> + (time_src) at a given moment (Tsrc). The host_tsc field is only valid
> + when the returned flags include KVM_CLOCK_HOST_TSC.
> +
> +2. For each vCPU[i]:
> +
> + a. Read the KVM_VCPU_TSC_OFFSET attribute to record the guest TSC offset
> + (ofs_src[i]).
> +
> + b. Read the KVM_VCPU_TSC_SCALE attribute to record the guest TSC scaling
> + ratio (ratio_src[i], frac_bits_src[i]). If the attribute is not
> + supported (-ENXIO), there is no hardware TSC scaling and identity
> + scaling applies: use ratio 1, frac_bits 0.
>
> -2. Read the KVM_VCPU_TSC_OFFSET attribute for every vCPU to record the
> - guest TSC offset (ofs_src[i]).
> + c. Use host_tsc_src and the scaling/offset factors to calculate this
> + vCPU's TSC at time Tsrc:
>
> -3. Invoke the KVM_GET_TSC_KHZ ioctl to record the frequency of the
> - guest's TSC (freq).
> + tsc_src[i] = ((host_tsc_src * ratio_src[i]) >> frac_bits_src[i]) + ofs_src[i]
> +
> + Note that frac_bits may be as high as 48, so this multiplication
> + needs a 128-bit intermediate to avoid overflow.
> +
> +3. Invoke the KVM_GET_CLOCK_GUEST ioctl on the boot vCPU to return the KVM
> + clock as a function of the guest TSC (pvti_src). (This ioctl may not
> + succeed if the host and guest TSCs are not consistent and well-behaved.)
[Severity: Low]
Previously, step 3 on the source side instructed the VMM to invoke
KVM_GET_TSC_KHZ to record the guest TSC frequency (freq), which was replaced
here by KVM_GET_CLOCK_GUEST.
However, destination step 4 and step 7b below still reference freq and
freq[i]:
tsc_dst[i] = tsc_src[i] + (ΔT * freq[i] / 10^6)
Should step 2 on the source side also include invoking KVM_GET_TSC_KHZ to
record freq[i] (or freq) for each vCPU?
> From the destination VMM process:
>
> -4. Invoke the KVM_SET_CLOCK ioctl, providing the source nanoseconds from
> - kvmclock (guest_src) and CLOCK_REALTIME (host_src) in their respective
> - fields. Ensure that the KVM_CLOCK_REALTIME flag is set in the provided
> - structure.
> +4. Invoke the KVM_SET_TSC_KHZ ioctl to set the scaled frequency of the
> + guest's TSC (freq) — either on the VM before creating the vCPUs, or
> + on each vCPU after creating it (as the exemplar test does).
> +
> +5. Invoke the KVM_GET_CLOCK ioctl to record the host TSC (host_tsc_dst) and
> + host CLOCK_REALTIME nanoseconds (time_dst) at a given moment (Tdst),
> + again checking KVM_CLOCK_HOST_TSC in the returned flags.
> +
> +6. Calculate the number of nanoseconds elapsed between Tsrc and Tdst:
> +
> + ΔT = time_dst - time_src
> +
> +7. As each vCPU[i] is created:
> +
> + a. Read the KVM_VCPU_TSC_SCALE attribute to record the guest TSC scaling
> + ratio (ratio_dst[i], frac_bits_dst[i]).
> +
> + b. Calculate the intended guest TSC value at time Tdst, taking care
> + with the units (ΔT is in nanoseconds; freq, as set by
> + KVM_SET_TSC_KHZ, is in kHz):
> +
> + tsc_dst[i] = tsc_src[i] + (ΔT * freq[i] / 10^6)
>
> - KVM will advance the VM's kvmclock to account for elapsed time since
> - recording the clock values. Note that this will cause problems in
> - the guest (e.g., timeouts) unless CLOCK_REALTIME is synchronized
> - between the source and destination, and a reasonably short time passes
> - between the source pausing the VMs and the destination executing
> - steps 4-7.
> + c. Use host_tsc_dst and the scaling factors to calculate this vCPU's
> + raw scaled TSC at time Tdst without offsetting:
> +
> + raw_dst[i] = ((host_tsc_dst * ratio_dst[i]) >> frac_bits_dst[i])
> +
> + d. Calculate ofs_dst[i] = tsc_dst[i] - raw_dst[i] and set the resulting
> + offset using the KVM_VCPU_TSC_OFFSET attribute.
> +
> +8. If pvti_src was provided, invoke the KVM_SET_CLOCK_GUEST ioctl on the boot
> + vCPU to restore the KVM clock as a precise function of the guest TSC.
[Severity: Low]
Can following steps 4, 7, and 8 as written cause KVM_SET_CLOCK_GUEST in step 8
to fail with -ENODATA when a VMM uses per-vCPU KVM_SET_TSC_KHZ?
Step 4 allows calling KVM_SET_TSC_KHZ on each vCPU after creating it, while
step 7 is described as happening "As each vCPU[i] is created". If a VMM
reads KVM_VCPU_TSC_SCALE in step 7a as each vCPU is created before calling
per-vCPU KVM_SET_TSC_KHZ, KVM_VCPU_TSC_SCALE will return the unscaled default
ratio (1 << tsc_frac_bits) rather than the scaled ratio for freq.
Furthermore, if a VMM creates and configures one vCPU at a time (creating
vCPU[0], calling per-vCPU KVM_SET_TSC_KHZ(vCPU[0], freq), and running step 7,
then creating vCPU[1]), creating vCPU[1] invokes:
kvm_arch_vcpu_create()
-> kvm_set_tsc_khz(vcpu, kvm->arch.default_tsc_khz)
-> __kvm_synchronize_tsc()
Because per-vCPU KVM_SET_TSC_KHZ does not update kvm->arch.default_tsc_khz,
vCPU[1] is initialized with the unscaled default_tsc_khz. In
arch/x86/kvm/x86.c:__kvm_synchronize_tsc():
if (vcpu->arch.virtual_tsc_khz != kvm->arch.cur_tsc_khz) {
kvm->arch.cur_tsc_freq_generation++;
kvm->arch.all_vcpus_matched_freq = false;
kvm->arch.nr_vcpus_matched_freq = 0;
}
This bumps cur_tsc_freq_generation to default_tsc_khz, and the subsequent
KVM_SET_TSC_KHZ(vCPU[1], freq) bumps cur_tsc_freq_generation again back to
freq, leaving vCPU[0] in an older generation with all_vcpus_matched_freq set
to false. When step 8 then invokes KVM_SET_CLOCK_GUEST,
pvclock_update_vm_gtod_copy() disables use_master_clock and
KVM_SET_CLOCK_GUEST fails with -ENODATA.
Should the documentation clarify that if per-vCPU KVM_SET_TSC_KHZ is used
instead of VM-scoped KVM_SET_TSC_KHZ, all vCPUs must be created and have
KVM_SET_TSC_KHZ applied before reading KVM_VCPU_TSC_SCALE and setting
KVM_VCPU_TSC_OFFSET in step 7?
[ ... ]
> diff --git a/tools/testing/selftests/kvm/x86/pvclock_migration_test.c b/tools/testing/selftests/kvm/x86/pvclock_migration_test.c
> new file mode 100644
> index 0000000000000..c4a64b6a2e429
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/x86/pvclock_migration_test.c
[ ... ]
> +static u64 pvclock_read_cycles(struct pvclock_vcpu_time_info *src,
> + u64 tsc)
> +{
> + u64 delta = tsc - src->tsc_timestamp;
> + u64 ns;
> +
> + if (src->tsc_shift >= 0)
> + delta <<= src->tsc_shift;
> + else
> + delta >>= -(s32)src->tsc_shift;
> +
> + ns = (unsigned __int128)delta * src->tsc_to_system_mul >> 32;
> + return src->system_time + ns;
> +}
[Severity: Low]
This isn't a bug, but pvclock_read_cycles() duplicates __pvclock_read_cycles()
from tools/arch/x86/include/asm/pvclock.h (already used by
tools/testing/selftests/kvm/x86/kvm_clock_test.c). In addition, main() later
open-codes the 128-bit TSC scaling calculation for raw_dst:
if (scale_dst.tsc_frac_bits)
raw_dst = (unsigned __int128)host_tsc_dst * scale_dst.tsc_ratio
>> scale_dst.tsc_frac_bits;
else
raw_dst = host_tsc_dst;
Could this test reuse __pvclock_read_cycles() and call
host_to_guest_tsc(&scale_dst, 0, host_tsc_dst) for raw_dst?
[ ... ]
> +int main(void)
> +{
> + struct pvclock_vcpu_time_info pvti_src[NR_VCPUS];
> + struct pvclock_vcpu_time_info pvti_dst_ioctl[NR_VCPUS];
> + struct kvm_clock_data clock_src, clock_dst;
> + struct kvm_vcpu_tsc_scale scale_src[NR_VCPUS], scale_dst;
> + struct kvm_vcpu *vcpus[NR_VCPUS];
> + struct kvm_vm *vm;
> + u64 mono_before, kvm_before, kvm_after;
> + s64 delta_before;
> + u64 ofs_src[NR_VCPUS], tsc_src[NR_VCPUS], tsc_dst, raw_dst;
> + u64 ofs_dst[NR_VCPUS];
> + u64 host_tsc_src, host_tsc_dst;
> + u64 time_src, time_dst;
> + s64 delta_t;
> + u32 freq_khz = 1500000; /* 1.5 GHz — forces TSC scaling */
> + int i, pass;
> +
> + TEST_REQUIRE(sys_clocksource_is_based_on_tsc());
> + TEST_REQUIRE(kvm_has_cap(KVM_CAP_TSC_CONTROL));
[Severity: Medium]
What happens if this selftest is run on a kernel that supports
KVM_CAP_TSC_CONTROL, but does not support KVM_CAP_CLOCK_GUEST (or
KVM_VCPU_TSC_SCALE)?
In main(), the subsequent calls to vcpu_get_clock_guest(),
vcpu_set_clock_guest(), and vcpu_device_attr_get(..., KVM_VCPU_TSC_CTRL,
KVM_VCPU_TSC_SCALE, ...) unconditionally assert ioctl success, so the test
will fail with an assertion abort instead of skipping.
Should main() also check TEST_REQUIRE(kvm_has_cap(KVM_CAP_CLOCK_GUEST)) (like
pvclock_test.c, masterclock_offset_test.c, and xen_migration_test.c) and
verify that the vCPU has KVM_VCPU_TSC_SCALE via __vcpu_has_device_attr()?
[ ... ]
> + /* Step 3: KVM_GET_CLOCK_GUEST (already fetched above as pvti_src[]) */
> +
> + kvm_vm_release(vm);
> +
> + /* === PAUSE (simulate migration) === */
> + pr_info("=== Pausing 1 second ===\n");
> + sleep(1);
> +
> + /* === DESTINATION SIDE === */
> + pr_info("=== Destination VM ===\n");
> + /* Step 4: create + KVM_SET_TSC_KHZ (in create_vm) */
> + vm = create_vm(vcpus, freq_khz);
[Severity: Low]
Does calling kvm_vm_release(vm) instead of kvm_vm_free(vm) here (and at the
end of main()) leak the VM's userspace_mem_regions mappings, sparsebit arrays,
and struct kvm_vm when vm is overwritten by create_vm()?
In tools/testing/selftests/kvm/lib/kvm_util.c, kvm_vm_release() only frees the
vCPUs and closes the KVM file descriptors, whereas kvm_vm_free() unmaps the
memory regions, frees vpages_valid and vpages_mapped, calls kvm_vm_release(),
and frees struct kvm_vm.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105154955.2525419-1-dwmw2@infradead.org?part=16
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v11 17/23] KVM: selftests: Add KVM/PV clock selftest to prove timer correction
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (15 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 16/23] KVM: x86: Add KVM_VCPU_TSC_SCALE and fix the documentation on TSC migration David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 15:49 ` [PATCH v11 18/23] KVM: selftests: Add master clock offset test David Woodhouse
` (5 subsequent siblings)
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: Jack Allister <jalliste@amazon.com>
A VM's KVM/PV clock has an inherent relationship to its TSC. When either
the host system live-updates or the VM is live-migrated this pairing of
the two clock sources should stay the same. In reality this is not the
case without some correction taking place.
The KVM_GET_CLOCK_GUEST/KVM_SET_CLOCK_GUEST ioctls can be used to
perform a correction on the PVTI (PV time information) structure held by
KVM to effectively fix up the kvmclock_offset prior to the guest VM
resuming in either a live-update/migration scenario.
This test proves that without the necessary fixup there is a perceived
change in the guest TSC and KVM/PV clock relationship before and after a
simulated LU/LM takes place, and that the correction eliminates it.
The test:
1. Snapshots the PVTI at boot (PVTI0).
2. Steps the KVM clock forward 10 seconds with KVM_SET_CLOCK and
induces a change in PVTI data, so the divergence the correction
must eliminate is deterministic.
3. Snapshots the PVTI after the change (PVTI1).
4. Requests correction via KVM_SET_CLOCK_GUEST using PVTI0.
5. Snapshots the PVTI after correction (PVTI2).
Then samples the TSC at a single point in time and calculates the KVM
clock using each PVTI snapshot, verifying that the uncorrected clock
diverged and that the corrected clock matches the boot clock to
within ±2ns.
Also test PVCLOCK_TSC_STABLE_BIT across matched, offset-mismatched
and frequency-mismatched vCPUs, and KVM_[GS]ET_CLOCK_GUEST on vCPUs
with divergent TSC offsets.
The test enumerates multiple TSC frequencies from 1GHz to 5GHz at 500MHz
steps, crossing the 32-bit boundary, to exercise the scaling path at
various ratios. The sleep duration between snapshots is configurable via
the -s/--sleep command line option.
Co-developed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Jack Allister <jalliste@amazon.com>
Reviewed-by: Paul Durrant <paul@xen.org>
Cc: Dongli Zhang <dongli.zhang@oracle.com>
---
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../testing/selftests/kvm/x86/pvclock_test.c | 447 ++++++++++++++++++
2 files changed, 448 insertions(+)
create mode 100644 tools/testing/selftests/kvm/x86/pvclock_test.c
diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index 18605318860e..15a1a8f64723 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -114,6 +114,7 @@ TEST_GEN_PROGS_x86 += x86/pmu_event_filter_test
TEST_GEN_PROGS_x86 += x86/private_mem_conversions_test
TEST_GEN_PROGS_x86 += x86/private_mem_kvm_exits_test
TEST_GEN_PROGS_x86 += x86/pvclock_migration_test
+TEST_GEN_PROGS_x86 += x86/pvclock_test
TEST_GEN_PROGS_x86 += x86/save_restore_pf_stress_test
TEST_GEN_PROGS_x86 += x86/set_boot_cpu_id
TEST_GEN_PROGS_x86 += x86/set_sregs_test
diff --git a/tools/testing/selftests/kvm/x86/pvclock_test.c b/tools/testing/selftests/kvm/x86/pvclock_test.c
new file mode 100644
index 000000000000..c63d9f636eda
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86/pvclock_test.c
@@ -0,0 +1,447 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright © Amazon.com, Inc. or its affiliates.
+ *
+ * Tests for pvclock API
+ * KVM_SET_CLOCK_GUEST/KVM_GET_CLOCK_GUEST
+ */
+#include <getopt.h>
+#include <stdint.h>
+#include <string.h>
+#include <time.h>
+#include <unistd.h>
+
+#include "test_util.h"
+#include "kvm_util.h"
+#include "processor.h"
+
+#include <asm/pvclock-abi.h>
+
+/*
+ * Reproduce the pvclock calculation the guest uses to convert TSC to
+ * nanoseconds. This must match the kernel's __pvclock_read_cycles().
+ */
+static inline u64 pvclock_scale_delta(u64 delta, u32 mul,
+ s8 shift)
+{
+ if (shift < 0)
+ delta >>= -shift;
+ else
+ delta <<= shift;
+ return ((__uint128_t)delta * mul) >> 32;
+}
+
+static inline u64 pvclock_read_cycles(struct pvclock_vcpu_time_info *src,
+ u64 tsc)
+{
+ u64 delta = tsc - src->tsc_timestamp;
+
+ return src->system_time + pvclock_scale_delta(delta,
+ src->tsc_to_system_mul,
+ src->tsc_shift);
+}
+
+static inline void pvti_snapshot(struct pvclock_vcpu_time_info *dst,
+ volatile struct pvclock_vcpu_time_info *src)
+{
+ u32 version;
+
+ do {
+ version = src->version;
+ __asm__ __volatile__("" ::: "memory");
+ *dst = *src;
+ __asm__ __volatile__("" ::: "memory");
+ } while ((src->version & 1) || src->version != version);
+}
+
+enum {
+ STAGE_FIRST_BOOT,
+ STAGE_UNCORRECTED,
+ STAGE_CORRECTED
+};
+
+#define KVMCLOCK_GPA 0xc0000000ull
+#define KVMCLOCK_SIZE sizeof(struct pvclock_vcpu_time_info)
+
+static void trigger_pvti_update(void)
+{
+ /*
+ * Toggle between KVM's old and new system time methods to coerce KVM
+ * into updating the fields in the PV time info struct.
+ */
+ wrmsr(MSR_KVM_SYSTEM_TIME, KVMCLOCK_GPA | KVM_MSR_ENABLED);
+ wrmsr(MSR_KVM_SYSTEM_TIME_NEW, KVMCLOCK_GPA | KVM_MSR_ENABLED);
+}
+
+static void guest_code(void)
+{
+ struct pvclock_vcpu_time_info *pvti =
+ (void *)(unsigned long)KVMCLOCK_GPA;
+ struct pvclock_vcpu_time_info pvti_boot;
+ struct pvclock_vcpu_time_info pvti_uncorrected;
+ struct pvclock_vcpu_time_info pvti_corrected;
+ u64 tsc_guest;
+ u64 clk_boot, clk_uncorrected, clk_corrected;
+ s64 delta_corrected;
+
+ /* Set up kvmclock and snapshot the initial pvclock parameters. */
+ wrmsr(MSR_KVM_SYSTEM_TIME_NEW, KVMCLOCK_GPA | KVM_MSR_ENABLED);
+ pvti_snapshot(&pvti_boot, pvti);
+ GUEST_SYNC(STAGE_FIRST_BOOT);
+
+ /*
+ * Trigger an update of the PVTI. Calculating the KVM clock using this
+ * updated structure will show a delta from the original.
+ */
+ trigger_pvti_update();
+ pvti_snapshot(&pvti_uncorrected, pvti);
+ GUEST_SYNC(STAGE_UNCORRECTED);
+
+ /*
+ * Snapshot the corrected time (the host does KVM_SET_CLOCK_GUEST when
+ * handling STAGE_UNCORRECTED).
+ */
+ pvti_snapshot(&pvti_corrected, pvti);
+
+ /*
+ * Sample the TSC at a single point in time, then calculate the
+ * effective KVM clock using the PVTI from each stage. Verify that the
+ * corrected clock matches the boot clock to within ±2ns.
+ */
+ tsc_guest = rdtsc();
+
+ clk_boot = pvclock_read_cycles(&pvti_boot, tsc_guest);
+ clk_uncorrected = pvclock_read_cycles(&pvti_uncorrected, tsc_guest);
+ clk_corrected = pvclock_read_cycles(&pvti_corrected, tsc_guest);
+
+ /*
+ * The host stepped the KVM clock forward by 10 seconds at
+ * STAGE_FIRST_BOOT, so the uncorrected clock must diverge; without
+ * this, a no-op KVM_SET_CLOCK_GUEST would pass the test below.
+ */
+ __GUEST_ASSERT((s64)(clk_uncorrected - clk_boot) > NSEC_PER_SEC,
+ "uncorrected clock did not diverge (boot=%lu uncorrected=%lu)",
+ clk_boot, clk_uncorrected);
+
+ delta_corrected = clk_boot - clk_corrected;
+
+ __GUEST_ASSERT(delta_corrected >= -2 && delta_corrected <= 2,
+ "corrected delta %ld out of range (boot=%lu uncorrected=%lu corrected=%lu)",
+ delta_corrected, clk_boot, clk_uncorrected, clk_corrected);
+
+ GUEST_SYNC(STAGE_CORRECTED);
+}
+
+static void run_test(struct kvm_vm *vm, struct kvm_vcpu *vcpu,
+ unsigned int sleep_sec)
+{
+ struct pvclock_vcpu_time_info pvti_before;
+ struct kvm_clock_data clock_step;
+ struct ucall uc;
+
+ for (;;) {
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
+
+ switch (get_ucall(vcpu, &uc)) {
+ case UCALL_ABORT:
+ REPORT_GUEST_ASSERT(uc);
+ break;
+ case UCALL_SYNC:
+ break;
+ default:
+ TEST_FAIL("Unexpected ucall");
+ }
+
+ switch (uc.args[1]) {
+ case STAGE_FIRST_BOOT:
+ /* Save the pvclock parameters before the update. */
+ vcpu_get_clock_guest(vcpu, &pvti_before);
+
+ /* Sleep to let the clocks diverge. */
+ sleep(sleep_sec);
+
+ /*
+ * Step the KVM clock forward 10 seconds so that the
+ * divergence the correction must eliminate is
+ * deterministic, not at the mercy of accumulated
+ * drift during the sleep.
+ */
+ vm_get_clock(vm, &clock_step);
+ clock_step.clock += 10ull * NSEC_PER_SEC;
+ clock_step.flags = 0;
+ vm_set_clock(vm, &clock_step);
+ break;
+
+ case STAGE_UNCORRECTED:
+ /* Restore the original pvclock parameters. */
+ vcpu_set_clock_guest(vcpu, &pvti_before);
+ break;
+
+ case STAGE_CORRECTED:
+ /* Guest verified the delta in-guest. */
+ return;
+
+ default:
+ TEST_FAIL("Unknown stage %lu", uc.args[1]);
+ }
+ }
+}
+
+static void configure_pvclock(struct kvm_vm *vm)
+{
+ unsigned int nr_pages;
+
+ nr_pages = vm_calc_num_guest_pages(VM_MODE_DEFAULT, getpagesize());
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS,
+ KVMCLOCK_GPA, 1, nr_pages, 0);
+ virt_map(vm, KVMCLOCK_GPA, KVMCLOCK_GPA, nr_pages);
+}
+
+static void run_at_frequency(u64 tsc_khz, unsigned int sleep_sec)
+{
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+
+ pr_info("Testing at TSC frequency %lu kHz\n", tsc_khz);
+ vm = vm_create_with_one_vcpu(&vcpu, guest_code);
+ configure_pvclock(vm);
+ vcpu_ioctl(vcpu, KVM_SET_TSC_KHZ, (void *)tsc_khz);
+ run_test(vm, vcpu, sleep_sec);
+ kvm_vm_free(vm);
+}
+
+static void test_tsc_stable_bit(void);
+static void test_clock_guest_with_offsets(void);
+
+static void usage(const char *name)
+{
+ printf("Usage: %s [options]\n"
+ " -s, --sleep SEC sleep duration between snapshots (default: 2)\n"
+ " -h, --help show this help\n", name);
+}
+
+int main(int argc, char *argv[])
+{
+ static const struct option long_opts[] = {
+ { "sleep", required_argument, NULL, 's' },
+ { "help", no_argument, NULL, 'h' },
+ { NULL, 0, NULL, 0 },
+ };
+ unsigned int sleep_sec = 2;
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ u64 host_khz;
+ u64 freq;
+ int opt;
+
+ while ((opt = getopt_long(argc, argv, "s:h", long_opts, NULL)) != -1) {
+ switch (opt) {
+ case 's':
+ sleep_sec = atoi_non_negative("sleep", optarg);
+ break;
+ case 'h':
+ default:
+ usage(argv[0]);
+ return opt == 'h' ? 0 : 1;
+ }
+ }
+
+ TEST_REQUIRE(sys_clocksource_is_based_on_tsc());
+ TEST_REQUIRE(kvm_has_cap(KVM_CAP_TSC_CONTROL));
+
+ TEST_REQUIRE(kvm_has_cap(KVM_CAP_CLOCK_GUEST));
+
+ vm = vm_create_with_one_vcpu(&vcpu, guest_code);
+ configure_pvclock(vm);
+
+ /* First run at native frequency (no scaling). */
+ run_test(vm, vcpu, sleep_sec);
+
+ /*
+ * Then enumerate a range of TSC frequencies crossing the 32-bit
+ * boundary, to exercise the scaling path at various ratios.
+ */
+ host_khz = __vcpu_ioctl(vcpu, KVM_GET_TSC_KHZ, NULL);
+ kvm_vm_free(vm);
+
+ for (freq = 1000000; freq <= 5000000; freq += 500000) {
+ if (freq == host_khz)
+ continue;
+ run_at_frequency(freq, sleep_sec);
+ }
+
+ test_tsc_stable_bit();
+ test_clock_guest_with_offsets();
+
+ return 0;
+}
+
+static volatile u32 vcpu_counter;
+static void guest_code_stable_bit(void)
+{
+ u32 idx = __atomic_fetch_add(&vcpu_counter, 1, __ATOMIC_SEQ_CST);
+ u64 gpa = KVMCLOCK_GPA + idx * KVMCLOCK_SIZE;
+
+ wrmsr(MSR_KVM_SYSTEM_TIME_NEW, gpa | KVM_MSR_ENABLED);
+ GUEST_SYNC(0);
+ GUEST_SYNC(0);
+ GUEST_SYNC(0);
+}
+
+static void run_vcpu_once(struct kvm_vcpu *vcpu)
+{
+ struct ucall uc;
+
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
+ switch (get_ucall(vcpu, &uc)) {
+ case UCALL_ABORT:
+ REPORT_GUEST_ASSERT(uc);
+ break;
+ case UCALL_SYNC:
+ break;
+ default:
+ TEST_FAIL("Unexpected ucall");
+ }
+}
+
+static void test_tsc_stable_bit(void)
+{
+ struct pvclock_vcpu_time_info pvti;
+ struct kvm_vcpu *vcpus[2];
+ struct kvm_vm *vm;
+ int ret;
+
+ pr_info("Testing PVCLOCK_TSC_STABLE_BIT with matched/unmatched TSCs\n");
+
+ vm = vm_create_with_vcpus(2, guest_code_stable_bit, vcpus);
+ configure_pvclock(vm);
+
+ /*
+ * Case 1: All TSCs matched (same frequency and offset).
+ * Master clock should be active, PVCLOCK_TSC_STABLE_BIT set.
+ */
+ run_vcpu_once(vcpus[0]);
+
+ vcpu_get_clock_guest(vcpus[0], &pvti);
+ TEST_ASSERT(pvti.flags & PVCLOCK_TSC_STABLE_BIT,
+ "PVCLOCK_TSC_STABLE_BIT should be set with matched TSCs");
+
+ /*
+ * Case 2: Different TSC offset, same frequency.
+ * Master clock should still be active (frequency matches), but
+ * PVCLOCK_TSC_STABLE_BIT should be cleared (offsets differ).
+ */
+ if (__vcpu_has_device_attr(vcpus[1], KVM_VCPU_TSC_CTRL,
+ KVM_VCPU_TSC_OFFSET)) {
+ pr_info(" Skipping offset test (KVM_VCPU_TSC_OFFSET not supported)\n");
+ goto case_freq;
+ }
+ vcpu_set_tsc_offset(vcpus[1], 12345678);
+ run_vcpu_once(vcpus[1]);
+ run_vcpu_once(vcpus[0]);
+
+ ret = __vcpu_get_clock_guest(vcpus[0], &pvti);
+ if (ret) {
+ /* Master clock disabled by offset mismatch — old kernel */
+ pr_info(" Skipping offset test (master clock requires matched offsets)\n");
+ goto case_freq;
+ }
+ TEST_ASSERT(!(pvti.flags & PVCLOCK_TSC_STABLE_BIT),
+ "PVCLOCK_TSC_STABLE_BIT should be clear with offset-mismatched TSCs");
+
+case_freq:
+ /*
+ * Case 3: Different TSC frequency.
+ * Master clock should be disabled entirely.
+ */
+ vcpu_ioctl(vcpus[1], KVM_SET_TSC_KHZ,
+ (void *)(unsigned long)(__vcpu_ioctl(vcpus[1], KVM_GET_TSC_KHZ, NULL) / 2));
+ /* Write TSC to trigger kvm_synchronize_tsc / kvm_track_tsc_matching */
+ vcpu_set_msr(vcpus[1], MSR_IA32_TSC, 0);
+ run_vcpu_once(vcpus[1]);
+
+ ret = __vcpu_get_clock_guest(vcpus[0], &pvti);
+ TEST_ASSERT(ret && errno == ENODATA,
+ "GET_CLOCK_GUEST should fail with frequency-mismatched TSCs, got %d (errno %d)",
+ ret, errno);
+
+ kvm_vm_free(vm);
+}
+
+static void test_clock_guest_with_offsets(void)
+{
+ struct pvclock_vcpu_time_info pvti0, pvti1, pvti1_after;
+ struct kvm_vcpu *vcpus[2];
+ struct kvm_vm *vm;
+ s64 delta;
+ int ret;
+
+ pr_info("Testing KVM_[GS]ET_CLOCK_GUEST with different TSC offsets\n");
+
+ vm = vm_create_with_vcpus(2, guest_code_stable_bit, vcpus);
+ configure_pvclock(vm);
+
+ /* Set different TSC offsets on the two vCPUs */
+ vcpu_set_tsc_offset(vcpus[0], 0);
+ vcpu_set_tsc_offset(vcpus[1], 1000000000ull);
+
+ /* Run both to establish kvmclock */
+ run_vcpu_once(vcpus[0]);
+ run_vcpu_once(vcpus[1]);
+
+ /* GET_CLOCK_GUEST on both — should succeed (master clock active) */
+ ret = __vcpu_get_clock_guest(vcpus[0], &pvti0);
+ if (ret) {
+ pr_info(" Skipping (master clock requires matched offsets on this kernel)\n");
+ kvm_vm_free(vm);
+ return;
+ }
+ vcpu_get_clock_guest(vcpus[1], &pvti1);
+
+ /* The tsc_timestamps should differ (different offsets) */
+ TEST_ASSERT(pvti0.tsc_timestamp != pvti1.tsc_timestamp,
+ "tsc_timestamps should differ with different offsets");
+
+ /* Sleep to let time elapse, then restore vcpu0's clock */
+ sleep(1);
+ vcpu_set_clock_guest(vcpus[0], &pvti0);
+
+ /* Run vcpu0 to process the clock update */
+ run_vcpu_once(vcpus[0]);
+
+ /*
+ * After SET on vcpu0, verify the correction worked by getting
+ * the clock on vcpu0 again. The mul/shift should be the same,
+ * and computing kvmclock at the same TSC should give the same
+ * result as the original (within ±2ns).
+ */
+ {
+ struct pvclock_vcpu_time_info pvti0_after;
+ u64 tsc_now, clk_from_old, clk_from_new;
+
+ vcpu_get_clock_guest(vcpus[0], &pvti0_after);
+
+ TEST_ASSERT(pvti0_after.tsc_to_system_mul == pvti0.tsc_to_system_mul &&
+ pvti0_after.tsc_shift == pvti0.tsc_shift,
+ "mul/shift changed across KVM_SET_CLOCK_GUEST");
+
+ tsc_now = pvti0_after.tsc_timestamp;
+ clk_from_old = pvclock_read_cycles(&pvti0, tsc_now);
+ clk_from_new = pvclock_read_cycles(&pvti0_after, tsc_now);
+
+ delta = (s64)clk_from_new - (s64)clk_from_old;
+ TEST_ASSERT(delta >= -2 && delta <= 2,
+ "clock correction delta should be <=2ns, got %ld ns",
+ delta);
+ }
+
+ /*
+ * Also verify that vcpu1's clock is still accessible (master
+ * clock still active with different offsets).
+ */
+ vcpu_get_clock_guest(vcpus[1], &pvti1_after);
+
+ kvm_vm_free(vm);
+}
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v11 18/23] KVM: selftests: Add master clock offset test
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (16 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 17/23] KVM: selftests: Add KVM/PV clock selftest to prove timer correction David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 20:25 ` sashiko-bot
2026-11-05 15:49 ` [PATCH v11 19/23] KVM: selftests: Add Xen/generic CPUID timing leaf test David Woodhouse
` (4 subsequent siblings)
22 siblings, 1 reply; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
Verify that KVM master clock mode remains active when vCPUs have
different TSC offsets but the same frequency. Creates three vCPUs,
sets one to a different TSC value, and confirms:
- KVM_CLOCK_HOST_TSC is set (master clock active)
- KVM_CLOCK_TSC_STABLE IS set (master clock ⇒ stable flag)
- PVCLOCK_TSC_STABLE_BIT is NOT set (offsets differ)
Then set the KVM clock forward one hour with KVM_SET_CLOCK and verify
that all vCPUs still agree on the KVM clock computed from their own
pvclock parameters.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../kvm/x86/masterclock_offset_test.c | 215 ++++++++++++++++++
2 files changed, 216 insertions(+)
create mode 100644 tools/testing/selftests/kvm/x86/masterclock_offset_test.c
diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index 15a1a8f64723..4d4eff41c525 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -95,6 +95,7 @@ TEST_GEN_PROGS_x86 += x86/hyperv_tlb_flush
TEST_GEN_PROGS_x86 += x86/kvm_clock_test
TEST_GEN_PROGS_x86 += x86/kvm_pv_test
TEST_GEN_PROGS_x86 += x86/kvm_buslock_test
+TEST_GEN_PROGS_x86 += x86/masterclock_offset_test
TEST_GEN_PROGS_x86 += x86/monitor_mwait_test
TEST_GEN_PROGS_x86 += x86/msrs_test
TEST_GEN_PROGS_x86 += x86/nested_close_kvm_test
diff --git a/tools/testing/selftests/kvm/x86/masterclock_offset_test.c b/tools/testing/selftests/kvm/x86/masterclock_offset_test.c
new file mode 100644
index 000000000000..47a1313eadc9
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86/masterclock_offset_test.c
@@ -0,0 +1,215 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Test that KVM master clock mode works with different TSC offsets
+ * as long as all vCPUs have the same TSC frequency.
+ */
+#include <string.h>
+
+#include "test_util.h"
+#include "kvm_util.h"
+#include "processor.h"
+
+#include <asm/pvclock-abi.h>
+
+#define KVMCLOCK_GPA 0xc0000000ull
+#define TSC_OFFSET (1000000000ULL)
+
+#define NR_VCPUS 3
+
+/* Read the per-vCPU pvclocks in an order other than creation order. */
+static const int vcpu_order[NR_VCPUS] = {0, 2, 1};
+
+static u64 pvclock_calc(struct pvclock_vcpu_time_info *pvti, u64 guest_tsc)
+{
+ u64 delta = guest_tsc - pvti->tsc_timestamp;
+
+ if (pvti->tsc_shift >= 0)
+ delta <<= pvti->tsc_shift;
+ else
+ delta >>= -(int)pvti->tsc_shift;
+
+ return pvti->system_time + ((__uint128_t)delta * pvti->tsc_to_system_mul >> 32);
+}
+
+static void guest_code(u64 pvti_gpa)
+{
+ wrmsr(MSR_KVM_SYSTEM_TIME_NEW, pvti_gpa | KVM_MSR_ENABLED);
+ for (;;)
+ GUEST_SYNC(0);
+}
+
+static void get_pvtis(struct kvm_vcpu **vcpus,
+ struct pvclock_vcpu_time_info *pvti)
+{
+ int i;
+
+ for (i = 0; i < NR_VCPUS; i++) {
+ int idx = vcpu_order[i];
+
+ vcpu_get_clock_guest(vcpus[idx], &pvti[idx]);
+ pr_info("vCPU %d: tsc_timestamp=%lu system_time=%lu "
+ "mul=%u shift=%d flags=0x%x\n",
+ idx, (unsigned long)pvti[idx].tsc_timestamp,
+ (unsigned long)pvti[idx].system_time,
+ pvti[idx].tsc_to_system_mul, pvti[idx].tsc_shift,
+ pvti[idx].flags);
+ }
+}
+
+/*
+ * Read the host TSC once and feed it through each vCPU's pvclock
+ * (adding each vCPU's TSC offset). All must compute exactly the same
+ * kvmclock value.
+ */
+static void assert_pvclocks_match(struct pvclock_vcpu_time_info *pvti,
+ u64 offset0, const char *what)
+{
+ u64 host_tsc, clk0, clk1, clk2;
+
+ host_tsc = rdtsc();
+ clk0 = pvclock_calc(&pvti[0], host_tsc + offset0);
+ clk1 = pvclock_calc(&pvti[1], host_tsc + offset0);
+ clk2 = pvclock_calc(&pvti[2], host_tsc + offset0 + TSC_OFFSET);
+
+ pr_info("%s: kvmclock via vCPU 0: %lu ns, vCPU 1: %lu ns, vCPU 2: %lu ns\n",
+ what, (unsigned long)clk0, (unsigned long)clk1,
+ (unsigned long)clk2);
+ TEST_ASSERT(clk0 == clk1 && clk0 == clk2,
+ "%s: kvmclock from all vCPUs should match exactly "
+ "(0: %lu, 1: %lu, 2: %lu)", what, (unsigned long)clk0,
+ (unsigned long)clk1, (unsigned long)clk2);
+}
+
+static void test_masterclock_active(struct kvm_vm *vm,
+ struct kvm_clock_data *clock)
+{
+ memset(clock, 0, sizeof(*clock));
+ vm_get_clock(vm, clock);
+ pr_info("KVM_GET_CLOCK flags: 0x%x\n", clock->flags);
+ TEST_ASSERT(clock->flags & KVM_CLOCK_HOST_TSC,
+ "Master clock should be active, flags=0x%x", clock->flags);
+ TEST_ASSERT(clock->flags & KVM_CLOCK_TSC_STABLE,
+ "KVM_CLOCK_TSC_STABLE should be set, flags=0x%x",
+ clock->flags);
+}
+
+static void test_offset_consistency(struct kvm_vcpu **vcpus,
+ struct pvclock_vcpu_time_info *pvti,
+ u64 offset0)
+{
+ u64 gtsc0, gtsc1, gtsc2;
+
+ get_pvtis(vcpus, pvti);
+
+ /* Read guest TSCs: should see (0+OFF) < 2 < (1+OFF) */
+ gtsc0 = vcpu_get_msr(vcpus[0], MSR_IA32_TSC);
+ gtsc2 = vcpu_get_msr(vcpus[2], MSR_IA32_TSC);
+ gtsc1 = vcpu_get_msr(vcpus[1], MSR_IA32_TSC);
+ pr_info("Guest TSCs: vcpu0=%lu vcpu2=%lu vcpu1=%lu\n",
+ (unsigned long)gtsc0, (unsigned long)gtsc2,
+ (unsigned long)gtsc1);
+ TEST_ASSERT(gtsc0 + TSC_OFFSET < gtsc2 && gtsc2 < gtsc1 + TSC_OFFSET,
+ "Expected (vcpu0+OFF) < vcpu2 < (vcpu1+OFF)");
+
+ /* PVCLOCK_TSC_STABLE_BIT should NOT be set (offsets differ) */
+ TEST_ASSERT(!(pvti[2].flags & PVCLOCK_TSC_STABLE_BIT),
+ "PVCLOCK_TSC_STABLE_BIT should NOT be set, flags=0x%x",
+ pvti[2].flags);
+
+ /* Same mul/shift */
+ TEST_ASSERT(pvti[0].tsc_to_system_mul == pvti[1].tsc_to_system_mul &&
+ pvti[0].tsc_to_system_mul == pvti[2].tsc_to_system_mul &&
+ pvti[0].tsc_shift == pvti[1].tsc_shift &&
+ pvti[0].tsc_shift == pvti[2].tsc_shift,
+ "All vCPUs should have same mul/shift");
+
+ assert_pvclocks_match(pvti, offset0, "Initial");
+}
+
+#define ONE_HOUR_NS (3600ULL * NSEC_PER_SEC)
+
+static void test_set_clock_consistency(struct kvm_vm *vm,
+ struct kvm_vcpu **vcpus,
+ struct pvclock_vcpu_time_info *pvti,
+ struct kvm_clock_data *clock,
+ u64 offset0)
+{
+ struct kvm_clock_data setclk = { .clock = clock->clock + ONE_HOUR_NS };
+ u64 clk0;
+ int i;
+
+ /*
+ * Add an hour to the VM kvmclock via KVM_SET_CLOCK, run each
+ * vCPU to pick up the update, and check they're still in sync.
+ */
+ vm_set_clock(vm, &setclk);
+
+ /* Guest code does GUEST_SYNC then exits — run each to see update */
+ for (i = 0; i < NR_VCPUS; i++) {
+ vcpu_run(vcpus[vcpu_order[i]]);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpus[vcpu_order[i]], KVM_EXIT_IO);
+ }
+
+ get_pvtis(vcpus, pvti);
+
+ TEST_ASSERT(pvti[0].system_time == pvti[1].system_time &&
+ pvti[0].system_time == pvti[2].system_time,
+ "system_time should still match after KVM_SET_CLOCK");
+
+ assert_pvclocks_match(pvti, offset0, "After +1h");
+
+ /* Verify the clock actually moved by ~1 hour */
+ clk0 = pvclock_calc(&pvti[0], rdtsc() + offset0);
+ TEST_ASSERT(clk0 > ONE_HOUR_NS,
+ "Clock should be > 1 hour after set, got %lu ns",
+ (unsigned long)clk0);
+}
+
+int main(void)
+{
+ struct pvclock_vcpu_time_info pvti[NR_VCPUS];
+ struct kvm_vcpu *vcpus[NR_VCPUS];
+ struct kvm_clock_data clock;
+ struct kvm_vm *vm;
+ u64 offset0;
+ int nr_pages;
+ int i;
+
+ TEST_REQUIRE(sys_clocksource_is_based_on_tsc());
+ TEST_REQUIRE(kvm_has_cap(KVM_CAP_CLOCK_GUEST));
+
+ vm = vm_create_with_vcpus(NR_VCPUS, guest_code, vcpus);
+
+ TEST_REQUIRE(!__vcpu_has_device_attr(vcpus[0], KVM_VCPU_TSC_CTRL,
+ KVM_VCPU_TSC_OFFSET));
+
+ nr_pages = vm_calc_num_guest_pages(VM_MODE_DEFAULT, getpagesize());
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS,
+ KVMCLOCK_GPA, 1, nr_pages, 0);
+ virt_map(vm, KVMCLOCK_GPA, KVMCLOCK_GPA, nr_pages);
+
+ /* Give each vCPU its own pvclock structure within the page */
+ for (i = 0; i < NR_VCPUS; i++)
+ vcpu_args_set(vcpus[i], 1, KVMCLOCK_GPA +
+ i * sizeof(struct pvclock_vcpu_time_info) * 2);
+
+ /* Get vCPU 0's default offset and set vCPU 2's offset higher */
+ offset0 = vcpu_get_tsc_offset(vcpus[0]);
+ vcpu_set_tsc_offset(vcpus[2], offset0 + TSC_OFFSET);
+
+ /* Run each vCPU to enable kvmclock (with offset already set) */
+ for (i = 0; i < NR_VCPUS; i++) {
+ vcpu_run(vcpus[i]);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpus[i], KVM_EXIT_IO);
+ }
+
+ test_masterclock_active(vm, &clock);
+ test_offset_consistency(vcpus, pvti, offset0);
+ pr_info("PASSED: pvclock consistent across offset vCPUs\n");
+
+ test_set_clock_consistency(vm, vcpus, pvti, &clock, offset0);
+ pr_info("PASSED: pvclock still consistent after KVM_SET_CLOCK +1h\n");
+
+ kvm_vm_free(vm);
+ return 0;
+}
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v11 18/23] KVM: selftests: Add master clock offset test
2026-11-05 15:49 ` [PATCH v11 18/23] KVM: selftests: Add master clock offset test David Woodhouse
@ 2026-11-05 20:25 ` sashiko-bot
0 siblings, 0 replies; 33+ messages in thread
From: sashiko-bot @ 2026-11-05 20:25 UTC (permalink / raw)
To: David Woodhouse, kvm
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] KVM: selftests: get_pvtis() never reads guest pvclock pages at KVMCLOCK_GPA
- [Low] KVM: selftests: pvclock_calc() and test duplicate pvclock helpers and tests
--
commit 5c47fcec1d956ca47ab8d39fceaff3ebcc1cad2e
Author: David Woodhouse <dwmw@amazon.co.uk>
KVM: selftests: Add master clock offset test
This commit adds a KVM selftest on x86 to verify that master clock mode
remains active and consistent across vCPUs when one vCPU is given a
different TSC offset and the VM clock is advanced with KVM_SET_CLOCK.
> diff --git a/tools/testing/selftests/kvm/x86/masterclock_offset_test.c b/tools/testing/selftests/kvm/x86/masterclock_offset_test.c
> new file mode 100644
> index 0000000000000..47a1313eadc9f
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/x86/masterclock_offset_test.c
> @@ -0,0 +1,215 @@
[ ... ]
> +static u64 pvclock_calc(struct pvclock_vcpu_time_info *pvti, u64 guest_tsc)
> +{
> + u64 delta = guest_tsc - pvti->tsc_timestamp;
> +
> + if (pvti->tsc_shift >= 0)
> + delta <<= pvti->tsc_shift;
> + else
> + delta >>= -(int)pvti->tsc_shift;
> +
> + return pvti->system_time + ((__uint128_t)delta * pvti->tsc_to_system_mul >> 32);
> +}
[Severity: Low]
This isn't a bug, but pvclock_calc() in
tools/testing/selftests/kvm/x86/masterclock_offset_test.c duplicates
__pvclock_read_cycles() from tools/arch/x86/include/asm/pvclock.h (already
used by tools/testing/selftests/kvm/x86/kvm_clock_test.c):
tools/arch/x86/include/asm/pvclock.h:__pvclock_read_cycles() {
u64 delta = tsc - src->tsc_timestamp;
u64 offset = pvclock_scale_delta(delta, src->tsc_to_system_mul,
src->tsc_shift);
return src->system_time + offset;
}
Also, tools/testing/selftests/kvm/x86/pvclock_test.c (in
test_tsc_stable_bit() and test_clock_guest_with_offsets()) and
tools/testing/selftests/kvm/x86/pvclock_migration_test.c (in
check_cross_vcpu_coherence()) already test master clock persistence,
PVCLOCK_TSC_STABLE_BIT clearing, and cross-vCPU pvclock agreement when vCPUs
have divergent TSC offsets.
Could this use __pvclock_read_cycles() and be folded as a test case into
tools/testing/selftests/kvm/x86/pvclock_test.c rather than adding a separate
test binary?
> +static void guest_code(u64 pvti_gpa)
> +{
> + wrmsr(MSR_KVM_SYSTEM_TIME_NEW, pvti_gpa | KVM_MSR_ENABLED);
> + for (;;)
> + GUEST_SYNC(0);
> +}
> +
> +static void get_pvtis(struct kvm_vcpu **vcpus,
> + struct pvclock_vcpu_time_info *pvti)
> +{
> + int i;
> +
> + for (i = 0; i < NR_VCPUS; i++) {
> + int idx = vcpu_order[i];
> +
> + vcpu_get_clock_guest(vcpus[idx], &pvti[idx]);
> + pr_info("vCPU %d: tsc_timestamp=%lu system_time=%lu "
> + "mul=%u shift=%d flags=0x%x\n",
> + idx, (unsigned long)pvti[idx].tsc_timestamp,
> + (unsigned long)pvti[idx].system_time,
> + pvti[idx].tsc_to_system_mul, pvti[idx].tsc_shift,
> + pvti[idx].flags);
> + }
> +}
[ ... ]
> +static void test_set_clock_consistency(struct kvm_vm *vm,
> + struct kvm_vcpu **vcpus,
> + struct pvclock_vcpu_time_info *pvti,
> + struct kvm_clock_data *clock,
> + u64 offset0)
> +{
> + struct kvm_clock_data setclk = { .clock = clock->clock + ONE_HOUR_NS };
> + u64 clk0;
> + int i;
> +
> + /*
> + * Add an hour to the VM kvmclock via KVM_SET_CLOCK, run each
> + * vCPU to pick up the update, and check they're still in sync.
> + */
> + vm_set_clock(vm, &setclk);
> +
> + /* Guest code does GUEST_SYNC then exits — run each to see update */
> + for (i = 0; i < NR_VCPUS; i++) {
> + vcpu_run(vcpus[vcpu_order[i]]);
> + TEST_ASSERT_KVM_EXIT_REASON(vcpus[vcpu_order[i]], KVM_EXIT_IO);
> + }
> +
> + get_pvtis(vcpus, pvti);
> +
> + TEST_ASSERT(pvti[0].system_time == pvti[1].system_time &&
> + pvti[0].system_time == pvti[2].system_time,
> + "system_time should still match after KVM_SET_CLOCK");
[ ... ]
> +int main(void)
> +{
[ ... ]
> + /* Give each vCPU its own pvclock structure within the page */
> + for (i = 0; i < NR_VCPUS; i++)
> + vcpu_args_set(vcpus[i], 1, KVMCLOCK_GPA +
> + i * sizeof(struct pvclock_vcpu_time_info) * 2);
> +
> + /* Get vCPU 0's default offset and set vCPU 2's offset higher */
> + offset0 = vcpu_get_tsc_offset(vcpus[0]);
> + vcpu_set_tsc_offset(vcpus[2], offset0 + TSC_OFFSET);
> +
> + /* Run each vCPU to enable kvmclock (with offset already set) */
> + for (i = 0; i < NR_VCPUS; i++) {
> + vcpu_run(vcpus[i]);
> + TEST_ASSERT_KVM_EXIT_REASON(vcpus[i], KVM_EXIT_IO);
> + }
[Severity: Medium]
Should get_pvtis() also inspect the guest-visible pvclock structures mapped
at KVMCLOCK_GPA rather than only calling vcpu_get_clock_guest()?
In main(), the test maps guest memory at KVMCLOCK_GPA, gives each vCPU its
own pvclock GPA, runs guest_code() to write MSR_KVM_SYSTEM_TIME_NEW, and in
test_set_clock_consistency() runs each vCPU after vm_set_clock() to refresh
the per-vCPU pvclock state.
However, get_pvtis() only calls vcpu_get_clock_guest()
(KVM_GET_CLOCK_GUEST). In arch/x86/kvm/x86.c,
kvm_vcpu_ioctl_get_clock_guest() does not read the guest pvclock page or go
through kvm_guest_time_update(); instead, it synthesizes hv_clock directly
from the VM-wide master clock fields in struct kvm_arch:
arch/x86/kvm/x86.c:kvm_vcpu_ioctl_get_clock_guest() {
...
hv_clock.tsc_timestamp = kvm_read_l1_tsc(v, ka->master_cycle_now);
hv_clock.system_time = ka->master_kernel_ns + ka->kvmclock_offset;
hv_clock.tsc_shift = ka->master_tsc_shift;
hv_clock.tsc_to_system_mul = ka->master_tsc_mul;
hv_clock.flags = READ_ONCE(ka->all_vcpus_matched_tsc) ?
PVCLOCK_TSC_STABLE_BIT : 0;
...
}
Because kvm_vm_ioctl_set_clock() updates ka->kvmclock_offset synchronously,
get_pvtis() never observes the guest memory at KVMCLOCK_GPA written by
kvm_guest_time_update(), and comparing system_time, tsc_to_system_mul, and
tsc_shift across vCPUs only compares the same VM-wide master_* fields to
themselves regardless of whether the vCPUs were run.
In addition, when main() calls vcpu_set_tsc_offset(vcpus[2], offset0 +
TSC_OFFSET), KVM_REQ_MASTERCLOCK_UPDATE is raised only on vcpus[2]. Running
vcpus[0], vcpus[1], and vcpus[2] in a single pass causes vcpus[0] and
vcpus[1] to populate their guest pvclock pages at KVMCLOCK_GPA before
vcpus[2] runs kvm_update_masterclock() and broadcasts KVM_REQ_CLOCK_UPDATE,
leaving the guest-visible pvclock pages for vcpus[0] and vcpus[1] with a
stale pre-update snapshot where PVCLOCK_TSC_STABLE_BIT is still set.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105154955.2525419-1-dwmw2@infradead.org?part=18
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v11 19/23] KVM: selftests: Add Xen/generic CPUID timing leaf test
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (17 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 18/23] KVM: selftests: Add master clock offset test David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 15:49 ` [PATCH v11 20/23] KVM: selftests: Add Xen runstate migration test David Woodhouse
` (3 subsequent siblings)
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
Verify that userspace can correctly populate Xen and generic CPUID
timing leaves using the KVM_GET_TSC_KHZ ioctl and
KVM_VCPU_TSC_SCALE attribute.
This validates that commit 7d3bd21e457b ("KVM: x86: Remove runtime Xen
TSC frequency CPUID update") doesn't break guests: userspace queries the effective TSC and bus
frequencies, computes the pvclock mul/shift, populates the CPUID leaves,
and the guest verifies the values match.
The test exercises:
- KVM_GET_TSC_KHZ at native and scaled frequencies
- KVM_VCPU_TSC_SCALE ratio verification against effective frequency
- Generic timing leaf 0x40000010 (EAX=tsc_khz, EBX=bus_khz)
- Xen leaf 3 sub-leaf 0 (ECX=guest TSC kHz)
- Xen leaf 3 sub-leaf 1 (ECX=mul, EDX=shift)
Where KVM_CAP_XEN_HVM is available, the guest is given the Xen
signature leaf and the Xen hypercall MSR is enabled — the exact
configuration in which the removed runtime update used to fire — and
a sentinel is planted in leaf 3 sub-leaf 2 EAX, where it used to
write, which the guest verifies survives untouched.
Gracefully skips TSC scaling tests on hardware without support, and
skips requested frequencies within tsc_tolerance_ppm of the host's,
where hardware scaling does not engage and the effective frequency is
the requested one with an identity ratio.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../selftests/kvm/x86/xen_cpuid_timing_test.c | 273 ++++++++++++++++++
2 files changed, 274 insertions(+)
create mode 100644 tools/testing/selftests/kvm/x86/xen_cpuid_timing_test.c
diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index 4d4eff41c525..79d26de18bf3 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -152,6 +152,7 @@ TEST_GEN_PROGS_x86 += x86/xss_msr_test
TEST_GEN_PROGS_x86 += x86/debug_regs
TEST_GEN_PROGS_x86 += x86/tsc_msrs_test
TEST_GEN_PROGS_x86 += x86/vmx_pmu_caps_test
+TEST_GEN_PROGS_x86 += x86/xen_cpuid_timing_test
TEST_GEN_PROGS_x86 += x86/xen_shinfo_test
TEST_GEN_PROGS_x86 += x86/xen_vmcall_test
TEST_GEN_PROGS_x86 += x86/sev_dbg_test
diff --git a/tools/testing/selftests/kvm/x86/xen_cpuid_timing_test.c b/tools/testing/selftests/kvm/x86/xen_cpuid_timing_test.c
new file mode 100644
index 000000000000..930ee9b8d51d
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86/xen_cpuid_timing_test.c
@@ -0,0 +1,273 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Test that userspace can correctly populate Xen and generic CPUID
+ * timing leaves using KVM_GET_TSC_KHZ and KVM_VCPU_TSC_SCALE.
+ *
+ * This validates that the removal of KVM's runtime Xen CPUID modification
+ * doesn't break guests, because userspace has all the information needed.
+ */
+#include <stdint.h>
+#include <stdlib.h>
+#include <string.h>
+
+#include "test_util.h"
+#include "kvm_util.h"
+#include "processor.h"
+
+
+#define XEN_CPUID_BASE 0x40000100
+#define XEN_CPUID_LEAF(n) (XEN_CPUID_BASE + (n))
+#define GENERIC_TIMING_LEAF 0x40000010
+
+/*
+ * Sentinel in Xen leaf 3 sub-leaf 2 EAX (where the removed runtime
+ * update used to write the vCPU's tsc_khz): it must survive untouched.
+ */
+#define XEN_SENTINEL 0xdeadbeef
+
+/* Values set by host, verified by guest */
+static u32 expected_tsc_khz;
+static u32 expected_bus_khz;
+static u32 expected_tsc_mul;
+static s8 expected_tsc_shift;
+static u64 host_khz;
+static bool xen_enabled;
+
+static void guest_code(void)
+{
+ u32 eax, ebx, ecx, edx;
+
+ /* Check generic timing leaf 0x40000010 */
+ __cpuid(GENERIC_TIMING_LEAF, 0, &eax, &ebx, &ecx, &edx);
+ GUEST_ASSERT_EQ(eax, expected_tsc_khz);
+ GUEST_ASSERT_EQ(ebx, expected_bus_khz);
+
+ /* Check Xen leaf 3, sub-leaf 0: ECX = guest TSC frequency */
+ __cpuid(XEN_CPUID_LEAF(3), 0, &eax, &ebx, &ecx, &edx);
+ GUEST_ASSERT_EQ(ecx, expected_tsc_khz);
+
+ /* Check Xen leaf 3, sub-leaf 1: ECX = mul, EDX = shift */
+ __cpuid(XEN_CPUID_LEAF(3), 1, &eax, &ebx, &ecx, &edx);
+ GUEST_ASSERT_EQ(ecx, expected_tsc_mul);
+ GUEST_ASSERT_EQ((s8)edx, expected_tsc_shift);
+
+ if (xen_enabled) {
+ /*
+ * With the Xen signature present and Xen enabled, verify the
+ * sentinel survives: KVM's removed runtime CPUID update used
+ * to clobber this sub-leaf for exactly this configuration.
+ */
+ __cpuid(XEN_CPUID_LEAF(3), 2, &eax, &ebx, &ecx, &edx);
+ GUEST_ASSERT_EQ(eax, XEN_SENTINEL);
+ }
+
+ GUEST_SYNC(0);
+}
+
+static void add_cpuid_entry(struct kvm_vcpu *vcpu, u32 function,
+ u32 index, u32 eax, u32 ebx,
+ u32 ecx, u32 edx)
+{
+ struct kvm_cpuid2 *cpuid = vcpu->cpuid;
+ struct kvm_cpuid_entry2 *entry;
+ int n = cpuid->nent;
+
+ cpuid = realloc(vcpu->cpuid,
+ sizeof(*cpuid) + (n + 1) * sizeof(*entry));
+ TEST_ASSERT(cpuid, "Failed to grow vCPU CPUID array");
+ vcpu->cpuid = cpuid;
+ cpuid->nent = n + 1;
+
+ entry = &cpuid->entries[n];
+ memset(entry, 0, sizeof(*entry));
+ entry->function = function;
+ entry->index = index;
+ entry->flags = KVM_CPUID_FLAG_SIGNIFCANT_INDEX;
+ entry->eax = eax;
+ entry->ebx = ebx;
+ entry->ecx = ecx;
+ entry->edx = edx;
+}
+
+/*
+ * Compute pvclock mul/shift from frequency, matching kvm_get_time_scale().
+ */
+static void compute_tsc_mul_shift(u64 tsc_hz, u32 *mul, s8 *shift)
+{
+ u64 scaled = 1000000000ULL;
+ u64 base = tsc_hz;
+ s32 s = 0;
+ u32 base32;
+
+ while (base > scaled * 2 || base >> 32) {
+ base >>= 1;
+ s--;
+ }
+ base32 = (u32)base;
+ while (base32 <= scaled || scaled >> 32) {
+ if (scaled >> 32 || base32 & (1U << 31))
+ scaled >>= 1;
+ else
+ base32 <<= 1;
+ s++;
+ }
+ *mul = (u32)((scaled << 32) / base32);
+ *shift = (s8)s;
+}
+
+static void run_test(u64 tsc_khz)
+{
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ struct ucall uc;
+ u32 effective_tsc_khz, effective_bus_khz;
+ int bus_cycle_ns, ret;
+
+ vm = vm_create_with_one_vcpu(&vcpu, guest_code);
+
+ if (tsc_khz) {
+ pr_info("Testing at TSC frequency %lu kHz\n", tsc_khz);
+ vcpu_ioctl(vcpu, KVM_SET_TSC_KHZ, (void *)(unsigned long)tsc_khz);
+ } else {
+ pr_info("Testing at native TSC frequency\n");
+ }
+
+ ret = __vcpu_ioctl(vcpu, KVM_GET_TSC_KHZ, NULL);
+ TEST_ASSERT(ret > 0, "KVM_GET_TSC_KHZ failed: %d", ret);
+ effective_tsc_khz = ret;
+ bus_cycle_ns = vm_check_cap(vm, KVM_CAP_X86_APIC_BUS_CYCLES_NS);
+ effective_bus_khz = bus_cycle_ns > 0 ? 1000000 / bus_cycle_ns : 1000000;
+
+ pr_info(" Effective TSC: %u kHz, Bus: %u kHz\n", effective_tsc_khz, effective_bus_khz);
+
+ /* Also exercise KVM_VCPU_TSC_SCALE if available */
+ if (!__vcpu_has_device_attr(vcpu, KVM_VCPU_TSC_CTRL,
+ KVM_VCPU_TSC_SCALE)) {
+ struct kvm_vcpu_tsc_scale scale;
+
+ vcpu_device_attr_get(vcpu, KVM_VCPU_TSC_CTRL,
+ KVM_VCPU_TSC_SCALE, &scale);
+ pr_info(" TSC scale: ratio=%llu frac_bits=%llu\n",
+ scale.tsc_ratio, scale.tsc_frac_bits);
+
+ /*
+ * A requested frequency within tsc_tolerance_ppm of the
+ * host's does not engage hardware scaling: the effective
+ * frequency is the requested one but the ratio stays 1.0,
+ * so the cross-check below cannot hold. Skip it.
+ */
+ if (tsc_khz &&
+ scale.tsc_ratio == (1ULL << scale.tsc_frac_bits)) {
+ pr_info(" Requested frequency within host tolerance; scaling not engaged, skipping\n");
+ kvm_vm_free(vm);
+ return;
+ }
+
+ /*
+ * Verify: applying the ratio to the host TSC frequency
+ * should give approximately the effective frequency.
+ */
+ if (tsc_khz) {
+ u64 computed = ((__uint128_t)host_khz * scale.tsc_ratio) >> scale.tsc_frac_bits;
+ s64 diff = (s64)computed - (s64)effective_tsc_khz;
+
+ TEST_ASSERT(diff >= -1 && diff <= 1,
+ "TSC_SCALE ratio mismatch: computed %lu vs effective %u (diff %ld)",
+ computed, effective_tsc_khz, diff);
+ }
+ }
+
+ compute_tsc_mul_shift((u64)effective_tsc_khz * 1000,
+ &expected_tsc_mul, &expected_tsc_shift);
+
+ expected_tsc_khz = effective_tsc_khz;
+ expected_bus_khz = effective_bus_khz;
+
+ sync_global_to_guest(vm, expected_tsc_khz);
+ sync_global_to_guest(vm, expected_bus_khz);
+ sync_global_to_guest(vm, expected_tsc_mul);
+ sync_global_to_guest(vm, expected_tsc_shift);
+
+ /* Populate CPUID leaves as a VMM would */
+ add_cpuid_entry(vcpu, GENERIC_TIMING_LEAF, 0,
+ effective_tsc_khz, effective_bus_khz, 0, 0);
+ add_cpuid_entry(vcpu, XEN_CPUID_LEAF(3), 0,
+ 0, 0, effective_tsc_khz, 0);
+ add_cpuid_entry(vcpu, XEN_CPUID_LEAF(3), 1,
+ 0, 0, expected_tsc_mul,
+ (u32)(s32)expected_tsc_shift);
+
+ /*
+ * Where possible, make this a real Xen guest: install the Xen
+ * signature leaf and enable the Xen hypercall MSR, which is the
+ * configuration in which KVM's removed runtime CPUID update used
+ * to fire, and plant a sentinel where it used to write.
+ */
+ xen_enabled = kvm_has_cap(KVM_CAP_XEN_HVM);
+ if (xen_enabled) {
+ struct kvm_xen_hvm_config cfg = {
+ .msr = 0x40000200,
+ };
+
+ vm_ioctl(vm, KVM_XEN_HVM_CONFIG, &cfg);
+ add_cpuid_entry(vcpu, XEN_CPUID_BASE, 0, XEN_CPUID_LEAF(4),
+ 0x566e6558 /* "XenV" */,
+ 0x65584d4d /* "MMXe" */,
+ 0x4d4d566e /* "nVMM" */);
+ add_cpuid_entry(vcpu, XEN_CPUID_LEAF(3), 2,
+ XEN_SENTINEL, 0, 0, 0);
+ }
+ sync_global_to_guest(vm, xen_enabled);
+
+ vcpu_set_cpuid(vcpu);
+
+ pr_info(" pvclock mul=%u shift=%d\n", expected_tsc_mul, expected_tsc_shift);
+
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
+
+ switch (get_ucall(vcpu, &uc)) {
+ case UCALL_ABORT:
+ REPORT_GUEST_ASSERT(uc);
+ break;
+ case UCALL_SYNC:
+ break;
+ default:
+ TEST_FAIL("Unexpected ucall");
+ }
+
+ kvm_vm_free(vm);
+}
+
+int main(void)
+{
+ u64 freq;
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ bool have_tsc_scale;
+
+ TEST_REQUIRE(sys_clocksource_is_based_on_tsc());
+
+ vm = vm_create_with_one_vcpu(&vcpu, guest_code);
+ have_tsc_scale = !__vcpu_has_device_attr(vcpu, KVM_VCPU_TSC_CTRL,
+ KVM_VCPU_TSC_SCALE);
+ host_khz = __vcpu_ioctl(vcpu, KVM_GET_TSC_KHZ, NULL);
+ kvm_vm_free(vm);
+
+ /* Native frequency */
+ run_test(0);
+
+ /* Scaled frequencies, when hardware TSC scaling is available */
+ if (have_tsc_scale) {
+ for (freq = 1000000; freq <= 4000000; freq += 1000000) {
+ if (freq == host_khz)
+ continue;
+ run_test(freq);
+ }
+ } else {
+ pr_info("Skipping scaled frequencies (no TSC scaling)\n");
+ }
+
+ pr_info("PASS: All CPUID timing leaf tests passed\n");
+ return 0;
+}
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v11 20/23] KVM: selftests: Add Xen runstate migration test
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (18 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 19/23] KVM: selftests: Add Xen/generic CPUID timing leaf test David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 15:49 ` [PATCH v11 21/23] KVM: selftests: Test that the first user TSC write is honoured exactly David Woodhouse
` (2 subsequent siblings)
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
Test that Xen runstate (steal time) is correctly accounted across a
simulated live migration using KVM_XEN_VCPU_ATTR and KVM_[GS]ET_CLOCK_GUEST.
The test simulates what a real VMM does during migration:
1. Creates a VM with Xen HVM config and runstate tracking
2. Runs the guest to accumulate some kvmclock time
3. Saves clock (KVM_GET_CLOCK_GUEST), TSC offset, and runstate
4. Marks the saved state as RUNSTATE_runnable (vCPU not running)
5. Destroys the source VM
6. Sleeps 10ms (simulating migration network transfer time)
7. Creates a new VM and restores all state precisely as saved
8. Runs the guest and verifies the migration gap appears as steal
The VM is placed in long mode explicitly (KVM_XEN_ATTR_TYPE_LONG_MODE)
so the kernel writes the 64-bit runstate layout; nothing in this test
writes the hypercall-page MSR, which is what would otherwise latch the
mode from the guest's EFER.
The guest TSC is transferred via the KVM_VCPU_TSC_OFFSET attribute. As
the "migration" is to a new VM on the same host, restoring the same
offset makes the guest TSC continue uninterrupted across the gap, so the
restored pvclock yields a kvmclock which has kept running too. That is
what makes the migration gap visible: the destination kvmclock is ahead
of the saved state_entry_time by (at least) the gap duration, rather
than restarting from the destination VM's creation time.
The kernel accounts the gap because: on vcpu_load, it transitions from
RUNSTATE_runnable to RUNSTATE_running, computing delta = kvmclock_now -
state_entry_time. Since kvmclock has advanced past the saved entry time
(real time elapsed during migration), the delta is added to time_runnable.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../selftests/kvm/x86/xen_migration_test.c | 222 ++++++++++++++++++
2 files changed, 223 insertions(+)
create mode 100644 tools/testing/selftests/kvm/x86/xen_migration_test.c
diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index 79d26de18bf3..1edc78845fd3 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -153,6 +153,7 @@ TEST_GEN_PROGS_x86 += x86/debug_regs
TEST_GEN_PROGS_x86 += x86/tsc_msrs_test
TEST_GEN_PROGS_x86 += x86/vmx_pmu_caps_test
TEST_GEN_PROGS_x86 += x86/xen_cpuid_timing_test
+TEST_GEN_PROGS_x86 += x86/xen_migration_test
TEST_GEN_PROGS_x86 += x86/xen_shinfo_test
TEST_GEN_PROGS_x86 += x86/xen_vmcall_test
TEST_GEN_PROGS_x86 += x86/sev_dbg_test
diff --git a/tools/testing/selftests/kvm/x86/xen_migration_test.c b/tools/testing/selftests/kvm/x86/xen_migration_test.c
new file mode 100644
index 000000000000..564781db3da2
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86/xen_migration_test.c
@@ -0,0 +1,222 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Test Xen runstate (steal time) preservation across simulated migration.
+ *
+ * Verifies that the kernel correctly accounts the migration gap as
+ * steal time (runnable) when runstate data is saved and restored
+ * precisely, but real time elapses during the migration.
+ *
+ * The key insight: userspace saves the runstate with state=RUNSTATE_runnable
+ * (the vCPU is not running during migration). On restore, the kernel sees
+ * that kvmclock has advanced past state_entry_time, and accounts the
+ * difference as time spent in the runnable state.
+ */
+#include <inttypes.h>
+#include <stdint.h>
+#include <stdio.h>
+#include <string.h>
+#include <unistd.h>
+
+#include "test_util.h"
+#include "kvm_util.h"
+#include "processor.h"
+
+#include <asm/pvclock-abi.h>
+
+#define SHINFO_GPA 0xc0000000ULL
+#define RUNSTATE_GPA (SHINFO_GPA + 0x1000)
+
+#define RUNSTATE_running 0
+#define RUNSTATE_runnable 1
+#define RUNSTATE_blocked 2
+#define RUNSTATE_offline 3
+
+/*
+ * The 64-bit (long mode) layout: 'state' is followed by 4 bytes of
+ * padding so state_entry_time is naturally aligned. The VM is placed
+ * in long mode explicitly below; without that, KVM would latch 32-bit
+ * mode (no hypercall-page write ever happens here to latch it from
+ * EFER) and write the packed compat layout instead.
+ */
+struct vcpu_runstate_info {
+ u32 state;
+ u64 state_entry_time;
+ u64 time[4];
+};
+
+static void guest_code(void)
+{
+ volatile struct vcpu_runstate_info *rs =
+ (void *)(unsigned long)RUNSTATE_GPA;
+
+ /* Report runstate times — no need to enable kvmclock MSR,
+ * the kernel writes runstate using its internal kvmclock. */
+ GUEST_SYNC_ARGS(0, rs->time[RUNSTATE_runnable],
+ rs->time[RUNSTATE_running], 0, 0);
+}
+
+static struct kvm_vm *create_xen_vm(struct kvm_vcpu **vcpu)
+{
+ struct kvm_vm *vm;
+ int xen_caps;
+
+ vm = vm_create_with_one_vcpu(vcpu, guest_code);
+
+ xen_caps = kvm_check_cap(KVM_CAP_XEN_HVM);
+ TEST_REQUIRE(xen_caps & KVM_XEN_HVM_CONFIG_SHARED_INFO);
+ TEST_REQUIRE(xen_caps & KVM_XEN_HVM_CONFIG_RUNSTATE);
+
+ /* Map pages */
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS,
+ SHINFO_GPA, 1, 2, 0);
+ virt_map(vm, SHINFO_GPA, SHINFO_GPA, 2);
+
+ /* Enable Xen HVM with MSR interception (enables runstate tracking) */
+ struct kvm_xen_hvm_config cfg = {
+ .flags = KVM_XEN_HVM_CONFIG_INTERCEPT_HCALL,
+ .msr = 0x40000000,
+ };
+ vm_ioctl(vm, KVM_XEN_HVM_CONFIG, &cfg);
+
+ /* The guest runs in long mode; make the runstate layout match. */
+ struct kvm_xen_hvm_attr lm = {
+ .type = KVM_XEN_ATTR_TYPE_LONG_MODE,
+ .u.long_mode = 1,
+ };
+ vm_ioctl(vm, KVM_XEN_HVM_SET_ATTR, &lm);
+
+ /* Set shared_info */
+ struct kvm_xen_hvm_attr ha = {
+ .type = KVM_XEN_ATTR_TYPE_SHARED_INFO,
+ .u.shared_info.gfn = SHINFO_GPA >> 12,
+ };
+ vm_ioctl(vm, KVM_XEN_HVM_SET_ATTR, &ha);
+
+ /* Set runstate address */
+ struct kvm_xen_vcpu_attr rs_addr = {
+ .type = KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_ADDR,
+ .u.gpa = RUNSTATE_GPA,
+ };
+ vcpu_ioctl(*vcpu, KVM_XEN_VCPU_SET_ATTR, &rs_addr);
+
+ return vm;
+}
+
+int main(void)
+{
+ struct pvclock_vcpu_time_info pvti;
+ struct kvm_xen_vcpu_attr runstate_save;
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ struct ucall uc;
+ u64 tsc_offset;
+ int ret;
+
+ TEST_REQUIRE(sys_clocksource_is_based_on_tsc());
+ TEST_REQUIRE(kvm_has_cap(KVM_CAP_CLOCK_GUEST));
+
+ /* === SOURCE SIDE === */
+ pr_info("=== Source: create VM and run guest ===\n");
+ vm = create_xen_vm(&vcpu);
+
+ /* Run guest once to accumulate some runstate time */
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
+ TEST_ASSERT_EQ(get_ucall(vcpu, &uc), UCALL_SYNC);
+
+ pr_info(" Guest sees: runnable=%" PRIu64 " running=%" PRIu64 "\n",
+ uc.args[2], uc.args[3]);
+
+ /* Save clock state */
+ vcpu_get_clock_guest(vcpu, &pvti);
+
+ /*
+ * Save the guest TSC offset. This test migrates to a new VM on
+ * the same host, so restoring the same offset makes the guest
+ * TSC continue uninterrupted across the migration gap, and the
+ * restored pvclock (KVM_SET_CLOCK_GUEST) then yields a kvmclock
+ * which has also kept running across the gap. (A real migration
+ * to a different host would compute the destination offset from
+ * KVM_GET_CLOCK's {host_tsc, realtime} pair as described in
+ * Documentation/virt/kvm/devices/vcpu.rst.)
+ */
+ tsc_offset = vcpu_get_tsc_offset(vcpu);
+
+ /* Save runstate — the vCPU is now "runnable" (not running) */
+ runstate_save.type = KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_DATA;
+ vcpu_ioctl(vcpu, KVM_XEN_VCPU_GET_ATTR, &runstate_save);
+
+ /*
+ * Transition to runnable state before saving — the vCPU is
+ * not running during migration.
+ */
+ runstate_save.u.runstate.state = RUNSTATE_runnable;
+
+ pr_info(" Saved runstate: running=%" PRIu64 " runnable=%" PRIu64
+ " entry=%" PRIu64 "\n",
+ (u64)runstate_save.u.runstate.time_running,
+ (u64)runstate_save.u.runstate.time_runnable,
+ (u64)runstate_save.u.runstate.state_entry_time);
+
+ u64 saved_runnable = runstate_save.u.runstate.time_runnable;
+
+ kvm_vm_free(vm);
+
+ /* === MIGRATION GAP === */
+ pr_info("=== Simulating migration (sleeping 10ms) ===\n");
+ usleep(10000);
+
+ /* === DESTINATION SIDE === */
+ pr_info("=== Destination: create new VM and restore ===\n");
+ vm = create_xen_vm(&vcpu);
+
+ /* Restore the guest TSC offset (same host: TSC continues) */
+ vcpu_set_tsc_offset(vcpu, tsc_offset);
+
+ /* Restore clock — kvmclock will now be ~10ms ahead of the snapshot */
+ vcpu_set_clock_guest(vcpu, &pvti);
+
+ /* Restore runstate exactly as saved (state=runnable) */
+ runstate_save.type = KVM_XEN_VCPU_ATTR_TYPE_RUNSTATE_DATA;
+ ret = __vcpu_ioctl(vcpu, KVM_XEN_VCPU_SET_ATTR, &runstate_save);
+ TEST_ASSERT(!ret, "Restore runstate failed: errno %d", errno);
+
+ /*
+ * Run the guest. When the vCPU enters vcpu_run, the kernel
+ * transitions from RUNSTATE_runnable to RUNSTATE_running.
+ * It computes: delta = kvmclock_now - state_entry_time
+ * This delta (which includes the migration gap) is added to
+ * time_runnable (steal time).
+ */
+ vcpu_run(vcpu);
+ TEST_ASSERT_KVM_EXIT_REASON(vcpu, KVM_EXIT_IO);
+ TEST_ASSERT_EQ(get_ucall(vcpu, &uc), UCALL_SYNC);
+
+ u64 guest_runnable = uc.args[2];
+ u64 guest_running = uc.args[3];
+
+ pr_info(" Guest sees: runnable=%" PRIu64 " running=%" PRIu64 "\n",
+ guest_runnable, guest_running);
+
+ u64 steal_increase = guest_runnable - saved_runnable;
+ pr_info(" Steal time increase: %" PRIu64 " ns (migration gap)\n",
+ steal_increase);
+
+ /*
+ * The steal time increase should be at least 10ms (the sleep).
+ * The actual gap runs from the source's state_entry_time to the
+ * destination's kvmclock "now" at vcpu_load time, which includes
+ * everything from the source guest's last runstate transition
+ * through VM teardown and re-creation — so the upper bound exists
+ * only to catch wild miscalculation (e.g. an unscaled TSC delta),
+ * and is deliberately generous for slow or loaded hosts.
+ */
+ TEST_ASSERT(steal_increase >= 10000000ULL &&
+ steal_increase < 60000000000ULL,
+ "Steal time increase %" PRIu64 " ns not in expected range "
+ "[10ms, 60s]", steal_increase);
+
+ kvm_vm_free(vm);
+ pr_info("PASS: Migration gap correctly accounted as steal time\n");
+ return 0;
+}
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v11 21/23] KVM: selftests: Test that the first user TSC write is honoured exactly
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (19 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 20/23] KVM: selftests: Add Xen runstate migration test David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 20:50 ` sashiko-bot
2026-11-05 15:49 ` [PATCH v11 22/23] KVM: x86/xen: Drop open-coded fallback clock read in kvm_xen_start_timer() David Woodhouse
2026-11-05 15:49 ` [PATCH v11 23/23] KVM: x86: Use a single time snapshot in kvm_vm_ioctl_set_clock() David Woodhouse
22 siblings, 1 reply; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
The 1-second "slop" heuristic in kvm_synchronize_tsc() is only
supposed to apply between successive userspace TSC writes, i.e. once
kvm->arch.user_set_tsc has been set by a previous write. The kernel's
own internal TSC synchronization on vCPU creation (and frequency
changes) must not arm it, otherwise the first genuine userspace write
falling within 1 second of virtual cycle time of the kernel's default
generation is "corrected" back to that generation instead of being
honoured — breaking the restore of a guest with less than one second
of runtime.
Add a test which creates a vCPU and immediately performs a first
host-initiated write of a TSC value corresponding to ~500ms of guest
runtime, then verifies the value reads back exactly (modulo elapsed
time) rather than being snapped back to the kernel's default
generation near zero.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
tools/testing/selftests/kvm/Makefile.kvm | 1 +
.../selftests/kvm/x86/tsc_user_set_test.c | 86 +++++++++++++++++++
2 files changed, 87 insertions(+)
create mode 100644 tools/testing/selftests/kvm/x86/tsc_user_set_test.c
diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
index 1edc78845fd3..fd063806a7fb 100644
--- a/tools/testing/selftests/kvm/Makefile.kvm
+++ b/tools/testing/selftests/kvm/Makefile.kvm
@@ -151,6 +151,7 @@ TEST_GEN_PROGS_x86 += x86/xcr0_cpuid_test
TEST_GEN_PROGS_x86 += x86/xss_msr_test
TEST_GEN_PROGS_x86 += x86/debug_regs
TEST_GEN_PROGS_x86 += x86/tsc_msrs_test
+TEST_GEN_PROGS_x86 += x86/tsc_user_set_test
TEST_GEN_PROGS_x86 += x86/vmx_pmu_caps_test
TEST_GEN_PROGS_x86 += x86/xen_cpuid_timing_test
TEST_GEN_PROGS_x86 += x86/xen_migration_test
diff --git a/tools/testing/selftests/kvm/x86/tsc_user_set_test.c b/tools/testing/selftests/kvm/x86/tsc_user_set_test.c
new file mode 100644
index 000000000000..6ab76e817f9f
--- /dev/null
+++ b/tools/testing/selftests/kvm/x86/tsc_user_set_test.c
@@ -0,0 +1,86 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Test that the first userspace write to MSR_IA32_TSC takes effect
+ * precisely, and is not subjected to the 1-second "slop" heuristic
+ * which is only supposed to apply between successive *userspace*
+ * writes (kvm->arch.user_set_tsc).
+ *
+ * The kernel synchronizes the TSC internally when a vCPU is created
+ * (and when its frequency is set). If any of those kernel-internal
+ * paths incorrectly sets user_set_tsc, then the first genuine write
+ * from userspace which happens to fall within 1 second of virtual
+ * cycle time of the kernel's default generation is "corrected" to
+ * match that generation instead of being honoured exactly. That
+ * breaks the restore of a guest which has genuinely been running
+ * for less than one second.
+ *
+ * Simulate exactly that: create a vCPU (kernel establishes a default
+ * TSC generation starting near zero), then perform the first
+ * host-initiated write with a value corresponding to ~500ms of guest
+ * runtime. If the slop heuristic fires, the written value is snapped
+ * back to the kernel's generation (near zero) and the TSC reads back
+ * hundreds of milliseconds low.
+ */
+#include "kvm_util.h"
+#include "processor.h"
+
+int main(void)
+{
+ struct kvm_vcpu *vcpu;
+ struct kvm_vm *vm;
+ u64 freq_khz, t_write, t_read, slack_cycles, mono_ns;
+ struct timespec ts;
+ int r;
+
+ /*
+ * Start the measured window before vCPU creation: a snapped-back
+ * value tracks time since the kernel's default generation (i.e.
+ * since creation), so the window the slack is derived from must
+ * include everything from creation onwards.
+ */
+ clock_gettime(CLOCK_MONOTONIC_RAW, &ts);
+ mono_ns = ts.tv_sec * 1000000000ULL + ts.tv_nsec;
+
+ vm = vm_create_with_one_vcpu(&vcpu, NULL);
+
+ r = __vcpu_ioctl(vcpu, KVM_GET_TSC_KHZ, NULL);
+ TEST_ASSERT(r > 0, "KVM_GET_TSC_KHZ failed");
+ freq_khz = r;
+
+ /*
+ * The first user write: a guest TSC corresponding to 500ms of
+ * runtime. This is within 1s (of virtual cycle time) of the
+ * kernel's default generation, so it is exactly the case that
+ * the slop heuristic would destroy if it were (incorrectly)
+ * armed by the kernel's own internal TSC synchronization.
+ */
+ t_write = freq_khz * 500ULL; /* khz * ms = cycles */
+
+ vcpu_set_msr(vcpu, MSR_IA32_TSC, t_write);
+
+ t_read = vcpu_get_msr(vcpu, MSR_IA32_TSC);
+
+ clock_gettime(CLOCK_MONOTONIC_RAW, &ts);
+ mono_ns = (ts.tv_sec * 1000000000ULL + ts.tv_nsec) - mono_ns;
+
+ /*
+ * The TSC advances between the write and the read; bound the
+ * difference by the measured elapsed time around the two ioctls
+ * plus 10ms of slop, so a descheduled test cannot flake. If the
+ * write was snapped to the kernel's default generation, the
+ * value read back is ~500ms low (i.e. below t_write), which is
+ * unambiguous.
+ */
+ slack_cycles = freq_khz * (mono_ns / 1000000ULL + 10);
+
+ TEST_ASSERT(t_read >= t_write,
+ "TSC went backwards from explicit write: wrote %lu, read %lu"
+ " (first userspace write was subjected to 1-second slop?)",
+ t_write, t_read);
+ TEST_ASSERT(t_read - t_write < slack_cycles,
+ "TSC read back too far from written value: wrote %lu, read %lu",
+ t_write, t_read);
+
+ kvm_vm_free(vm);
+ return 0;
+}
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: [PATCH v11 21/23] KVM: selftests: Test that the first user TSC write is honoured exactly
2026-11-05 15:49 ` [PATCH v11 21/23] KVM: selftests: Test that the first user TSC write is honoured exactly David Woodhouse
@ 2026-11-05 20:50 ` sashiko-bot
0 siblings, 0 replies; 33+ messages in thread
From: sashiko-bot @ 2026-11-05 20:50 UTC (permalink / raw)
To: David Woodhouse, kvm
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] KVM: selftests: misplaced timing window and missing KVM_SET_TSC_KHZ in main()
- [Low] KVM: selftests: duplicate MSR_IA32_TSC test binary and helpers
--
commit c39adcb632ae1981c065df1ae8906c472090451f
Author: David Woodhouse <dwmw@amazon.co.uk>
KVM: selftests: Test that the first user TSC write is honoured exactly
This commit adds an x86 KVM selftest that creates a vCPU, writes a guest TSC
value corresponding to 500ms of runtime via MSR_IA32_TSC, and checks that the
value reads back without being snapped back to the default generation by the
1-second slop heuristic in kvm_synchronize_tsc().
> diff --git a/tools/testing/selftests/kvm/Makefile.kvm b/tools/testing/selftests/kvm/Makefile.kvm
> index 1edc78845fd35..fd063806a7fb9 100644
> --- a/tools/testing/selftests/kvm/Makefile.kvm
> +++ b/tools/testing/selftests/kvm/Makefile.kvm
> @@ -151,6 +151,7 @@ TEST_GEN_PROGS_x86 += x86/xcr0_cpuid_test
> TEST_GEN_PROGS_x86 += x86/xss_msr_test
> TEST_GEN_PROGS_x86 += x86/debug_regs
> TEST_GEN_PROGS_x86 += x86/tsc_msrs_test
> +TEST_GEN_PROGS_x86 += x86/tsc_user_set_test
[Severity: Low]
This isn't a bug, but tools/testing/selftests/kvm/x86/tsc_msrs_test.c already
tests host and guest reads and writes to MSR_IA32_TSC and MSR_IA32_TSC_ADJUST.
Should this narrow MSR_IA32_TSC host-write check be added as a test case in
x86/tsc_msrs_test.c rather than introducing a separate standalone test binary?
> diff --git a/tools/testing/selftests/kvm/x86/tsc_user_set_test.c b/tools/testing/selftests/kvm/x86/tsc_user_set_test.c
> new file mode 100644
> index 0000000000000..6ab76e817f9fe
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/x86/tsc_user_set_test.c
> @@ -0,0 +1,86 @@
[ ... ]
> +int main(void)
> +{
> + struct kvm_vcpu *vcpu;
> + struct kvm_vm *vm;
> + u64 freq_khz, t_write, t_read, slack_cycles, mono_ns;
> + struct timespec ts;
> + int r;
> +
> + /*
> + * Start the measured window before vCPU creation: a snapped-back
> + * value tracks time since the kernel's default generation (i.e.
> + * since creation), so the window the slack is derived from must
> + * include everything from creation onwards.
> + */
> + clock_gettime(CLOCK_MONOTONIC_RAW, &ts);
> + mono_ns = ts.tv_sec * 1000000000ULL + ts.tv_nsec;
> +
> + vm = vm_create_with_one_vcpu(&vcpu, NULL);
> +
> + r = __vcpu_ioctl(vcpu, KVM_GET_TSC_KHZ, NULL);
> + TEST_ASSERT(r > 0, "KVM_GET_TSC_KHZ failed");
> + freq_khz = r;
[Severity: Low]
This isn't a bug, but vm_create_with_one_vcpu() calls
kvm_arch_vm_post_create(), which already invokes KVM_GET_TSC_KHZ, asserts that
it succeeded, and stores the result in the global guest_tsc_khz. In addition,
test_util.h (included via kvm_util.h) provides timespec_to_ns() and
timespec_sub(). Could main() reuse guest_tsc_khz and timespec_to_ns() instead
of re-querying KVM_GET_TSC_KHZ and open-coding the timespec conversion?
> +
> + /*
> + * The first user write: a guest TSC corresponding to 500ms of
> + * runtime. This is within 1s (of virtual cycle time) of the
> + * kernel's default generation, so it is exactly the case that
> + * the slop heuristic would destroy if it were (incorrectly)
> + * armed by the kernel's own internal TSC synchronization.
> + */
> + t_write = freq_khz * 500ULL; /* khz * ms = cycles */
> +
> + vcpu_set_msr(vcpu, MSR_IA32_TSC, t_write);
> +
> + t_read = vcpu_get_msr(vcpu, MSR_IA32_TSC);
> +
> + clock_gettime(CLOCK_MONOTONIC_RAW, &ts);
> + mono_ns = (ts.tv_sec * 1000000000ULL + ts.tv_nsec) - mono_ns;
> +
> + /*
> + * The TSC advances between the write and the read; bound the
> + * difference by the measured elapsed time around the two ioctls
> + * plus 10ms of slop, so a descheduled test cannot flake. If the
> + * write was snapped to the kernel's default generation, the
> + * value read back is ~500ms low (i.e. below t_write), which is
> + * unambiguous.
> + */
> + slack_cycles = freq_khz * (mono_ns / 1000000ULL + 10);
> +
> + TEST_ASSERT(t_read >= t_write,
> + "TSC went backwards from explicit write: wrote %lu, read %lu"
> + " (first userspace write was subjected to 1-second slop?)",
> + t_write, t_read);
> + TEST_ASSERT(t_read - t_write < slack_cycles,
> + "TSC read back too far from written value: wrote %lu, read %lu",
> + t_write, t_read);
[Severity: Medium]
Should the initial clock_gettime(CLOCK_MONOTONIC_RAW, &ts) call in main() be
placed immediately before vcpu_set_msr(vcpu, MSR_IA32_TSC, t_write) rather
than before vm_create_with_one_vcpu(&vcpu, NULL)?
When the kernel honours vcpu_set_msr(vcpu, MSR_IA32_TSC, t_write), the guest
TSC is set to t_write at the time of vcpu_set_msr() and only advances between
vcpu_set_msr() and vcpu_get_msr(), matching the second comment that
slack_cycles bounds the elapsed time around the two MSR ioctls.
Conversely, if a buggy kernel snaps the write back to the default generation
established during vCPU creation, t_read tracks the elapsed time since vCPU
creation. Because mono_ns is measured from before vm_create_with_one_vcpu(),
t_read is always less than mono_ns, so t_read - t_write < slack_cycles is
guaranteed to hold for any snapped-back value. If vm_create_with_one_vcpu()
takes between 500ms and 1500ms on a loaded host, a snapped-back TSC will
satisfy both t_read >= t_write and t_read - t_write < slack_cycles, causing
the test to pass on a buggy kernel.
Also, both the commit message and the file header comment note that
kernel-internal TSC synchronization on vCPU creation and frequency changes
must not arm user_set_tsc. During kvm_arch_vcpu_create(), kvm_set_tsc_khz()
runs while l1_tsc_scaling_ratio and l1_tsc_offset are still zero, whereas an
explicit KVM_SET_TSC_KHZ ioctl on an existing vCPU runs with non-zero
l1_tsc_scaling_ratio and l1_tsc_offset. Should main() also test calling
KVM_SET_TSC_KHZ before the first MSR_IA32_TSC write?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261105154955.2525419-1-dwmw2@infradead.org?part=21
^ permalink raw reply [flat|nested] 33+ messages in thread
* [PATCH v11 22/23] KVM: x86/xen: Drop open-coded fallback clock read in kvm_xen_start_timer()
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (20 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 21/23] KVM: selftests: Test that the first user TSC write is honoured exactly David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
2026-11-05 15:49 ` [PATCH v11 23/23] KVM: x86: Use a single time snapshot in kvm_vm_ioctl_set_clock() David Woodhouse
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
When no coherent (CLOCK_MONOTONIC, TSC) pair was available,
kvm_xen_start_timer() computed one from separate ktime_get() and
rdtsc() calls rather than using get_kvmclock_ns(), with a comment
explaining that the latter had a systemic error from scaling host TSC
directly to nanoseconds instead of scaling to the guest TSC first.
Commit abdef42276d8 ("KVM: x86: Fix KVM clock precision in
get_kvmclock() with TSC scaling") removed that systemic error: in
master clock mode, get_kvmclock_ns() now scales the host TSC delta to
the guest TSC and converts it with the guest's own mul/shift,
computing precisely what the guest would.
The fallback is also nearly unreachable. It sits behind the
use_master_clock check, so on 32-bit (where the master clock is never
active) it is dead code, and on 64-bit kvm_get_monotonic_and_clockread()
can only fail there if the host clocksource changed after the last
master clock update, in the window before the resulting masterclock
update is processed. In exactly that window get_kvmclock_ns() takes
its raw-clock fallback path rather than the guest TSC computation,
which is continuous with the last valid snapshot and tolerable for
the one timer that can be started before the pending masterclock
update lands.
Drop it and fall back to the existing get_kvmclock_ns() path.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/kvm/xen.c | 40 +++++++++++++++++++---------------------
1 file changed, 19 insertions(+), 21 deletions(-)
diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
index 6aa00f746cba..dbac3d2c04d7 100644
--- a/arch/x86/kvm/xen.c
+++ b/arch/x86/kvm/xen.c
@@ -230,22 +230,19 @@ static void kvm_xen_start_timer(struct kvm_vcpu *vcpu, u64 guest_abs,
if (r)
break;
+ /*
+ * With use_master_clock set, the clocksource was TSC-based
+ * when the master clock was last updated. The clockread can
+ * only fail here if the clocksource has changed since, in
+ * which case a masterclock update is already pending and
+ * get_kvmclock_ns() returns the raw-clock fallback value —
+ * continuous with the last valid snapshot, which is as good
+ * as it gets in that transient window.
+ */
if (!IS_ENABLED(CONFIG_64BIT) ||
!kvm_get_monotonic_and_clockread(&kernel_now, &host_tsc)) {
- /*
- * Don't fall back to get_kvmclock_ns() because it's
- * broken; it has a systemic error in its results
- * because it scales directly from host TSC to
- * nanoseconds, and doesn't scale first to guest TSC
- * and *then* to nanoseconds as the guest does.
- *
- * There is a small error introduced here because time
- * continues to elapse between the ktime_get() and the
- * subsequent rdtsc(). But not the systemic drift due
- * to get_kvmclock_ns().
- */
- kernel_now = ktime_get(); /* This is CLOCK_MONOTONIC */
- host_tsc = rdtsc();
+ r = -EOPNOTSUPP;
+ break;
}
/* Calculate the guest kvmclock as the guest would do it. */
@@ -255,18 +252,19 @@ static void kvm_xen_start_timer(struct kvm_vcpu *vcpu, u64 guest_abs,
if (r) {
/*
- * Without CONSTANT_TSC, get_kvmclock_ns() is the only option.
+ * Without CONSTANT_TSC and the master clock,
+ * get_kvmclock_ns() is the only option.
*
* Also if the guest PV clock hasn't been set up yet, as is
* likely to be the case during migration when the vCPU has
* not been run yet. It would be possible to calculate the
* scaling factors properly in that case but there's not much
- * point in doing so. The get_kvmclock_ns() drift accumulates
- * over time, so it's OK to use it at startup. Besides, on
- * migration there's going to be a little bit of skew in the
- * precise moment at which timers fire anyway. Often they'll
- * be in the "past" by the time the VM is running again after
- * migration.
+ * point in doing so. Without the master clock, the
+ * get_kvmclock_ns() drift accumulates over time, so it's OK
+ * to use it at startup. Besides, on migration there's going
+ * to be a little bit of skew in the precise moment at which
+ * timers fire anyway. Often they'll be in the "past" by the
+ * time the VM is running again after migration.
*/
guest_now = get_kvmclock_ns(vcpu->kvm);
kernel_now = ktime_get();
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread* [PATCH v11 23/23] KVM: x86: Use a single time snapshot in kvm_vm_ioctl_set_clock()
2026-11-05 15:49 [PATCH v11 00/23] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
` (21 preceding siblings ...)
2026-11-05 15:49 ` [PATCH v11 22/23] KVM: x86/xen: Drop open-coded fallback clock read in kvm_xen_start_timer() David Woodhouse
@ 2026-11-05 15:49 ` David Woodhouse
22 siblings, 0 replies; 33+ messages in thread
From: David Woodhouse @ 2026-11-05 15:49 UTC (permalink / raw)
To: kvm
Cc: linux-kernel, linux-kselftest, linux-doc, xen-devel, x86,
Paolo Bonzini, Sean Christopherson, Paul Durrant,
Vitaly Kuznetsov, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, H . Peter Anvin, Jonathan Corbet, Shuah Khan,
Juergen Gross, Boris Ostrovsky, Jonathan Cameron, Sascha Bischoff,
Marc Zyngier, Joey Gouly, Jack Allister, Dongli Zhang, joe.jin,
David Woodhouse
From: David Woodhouse <dwmw@amazon.co.uk>
The KVM_CLOCK_REALTIME handling read CLOCK_REALTIME with
ktime_get_real_ns() and then anchored the result at a different
instant: the master clock reference point captured a few lines
earlier, or a separate get_kvmclock_base_ns() read. The time elapsed
between the two reads is added to the restored clock as error --
bounded by the interrupts-off critical section, but gratuitous now
that the timekeeping core can snapshot CLOCK_REALTIME and
CLOCK_MONOTONIC_RAW at the same instant.
Take one ktime_get_snapshot_id(CLOCK_REALTIME) snapshot and derive
both the realtime correction and the raw reference point from it. In
master clock mode, keep anchoring at master_kernel_ns -- so that
'system_time' cannot go negative for a very small data.clock, as the
existing comment explains -- by projecting the snapshot's realtime
value back to that reference point; CLOCK_REALTIME and
CLOCK_MONOTONIC_RAW tick at the same rate across the few ns in
between, give or take NTP slew.
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
arch/x86/kvm/x86.c | 32 +++++++++++++++++++++++++++-----
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 17544b3cc035..4db0c809d120 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4693,19 +4693,41 @@ static int kvm_vm_ioctl_set_clock(struct kvm *kvm, void __user *argp)
* 'system_time' when 'data.clock' is very small.
*/
if (data.flags & KVM_CLOCK_REALTIME) {
- u64 now_real_ns = ktime_get_real_ns();
+ struct system_time_snapshot snap = {};
+ u64 now_real_ns;
+
+ /*
+ * Snapshot CLOCK_REALTIME and CLOCK_MONOTONIC_RAW at the
+ * same instant, so that the elapsed time applied to
+ * data.clock and the reference point the result is anchored
+ * to are coherent.
+ */
+ ktime_get_snapshot_id(CLOCK_REALTIME, &snap);
+ now_real_ns = ktime_to_ns(snap.systime);
+ now_raw_ns = ktime_to_ns(ktime_mono_to_any(snap.monoraw,
+ TK_OFFS_BOOT));
+
+ /*
+ * When the master clock is in use, anchor at its reference
+ * point instead, projecting the realtime value back to the
+ * same instant. The two clocks tick at the same rate across
+ * the few ns in between, give or take NTP slew.
+ */
+ if (ka->use_master_clock) {
+ now_real_ns -= now_raw_ns - ka->master_kernel_ns;
+ now_raw_ns = ka->master_kernel_ns;
+ }
/*
* Avoid stepping the kvmclock backwards.
*/
if (now_real_ns > data.realtime)
data.clock += now_real_ns - data.realtime;
- }
-
- if (ka->use_master_clock)
+ } else if (ka->use_master_clock) {
now_raw_ns = ka->master_kernel_ns;
- else
+ } else {
now_raw_ns = get_kvmclock_base_ns();
+ }
ka->kvmclock_offset = data.clock - now_raw_ns;
kvm_end_pvclock_update(kvm);
return 0;
--
2.43.0
^ permalink raw reply related [flat|nested] 33+ messages in thread