Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "David Woodhouse" <dwmw2@infradead.org>, kvm@vger.kernel.org
Subject: Re: [PATCH v12 18/24] KVM: selftests: Add master clock offset test
Date: Mon, 09 Nov 2026 01:47:27 +0000	[thread overview]
Message-ID: <sashiko-outbox-204320@kernel.org> (raw)
In-Reply-To: <20261109012112.3415328-19-dwmw2@infradead.org>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] KVM: selftests: get_pvtis() never reads guest pvclock pages
  at KVMCLOCK_GPA
--

commit afe5627be945a0319bdf870a16137575eb9a6ca5
Author: David Woodhouse <dwmw@amazon.co.uk>

KVM: selftests: Add master clock offset test

This commit adds an x86 KVM selftest to verify that master clock mode
remains active and pvclock readings stay consistent across vCPUs with
different TSC offsets, both initially and after advancing the clock via
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..faf81872538eb
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/x86/masterclock_offset_test.c
> @@ -0,0 +1,203 @@

[ ... ]

> +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]);

[ ... ]

> +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");

[Severity: Medium]
Should get_pvtis() read the per-vCPU pvclock_vcpu_time_info structures
from guest memory at KVMCLOCK_GPA (or check both guest memory and
vcpu_get_clock_guest())?

The test sets up guest memory at KVMCLOCK_GPA, enables
MSR_KVM_SYSTEM_TIME_NEW in guest_code(), and runs each vCPU after
vm_set_clock() so kvm_guest_time_update() refreshes the guest pvclock
structures.  However, get_pvtis() only calls vcpu_get_clock_guest()
(KVM_GET_CLOCK_GUEST), which synthesizes hv_clock directly from the
VM-wide master clock fields in struct kvm_arch without reading the guest
pvclock pages:

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;
	...
}

As a result, the guest memory at KVMCLOCK_GPA is never inspected, and
checking that tsc_to_system_mul, tsc_shift, and system_time match across
vCPUs compares the same VM-wide ka->master_* fields against themselves
regardless of whether vcpu_run() updated the guest pvclock structures.
In addition, because vcpu_set_tsc_offset() on vcpus[2] in main() queues
KVM_REQ_MASTERCLOCK_UPDATE only on vcpus[2], running vcpus[0..2] once in
order populates the guest pvclock structures for vcpus[0] and vcpus[1]
before vcpus[2] runs kvm_update_masterclock() and broadcasts
KVM_REQ_CLOCK_UPDATE, leaving vcpus[0] and vcpus[1] with stale guest
memory state until the next vcpu_run().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109012112.3415328-1-dwmw2@infradead.org?part=18

  reply	other threads:[~2026-11-09  1:47 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09  1:20 [PATCH v12 00/24] KVM: x86: Cleaning up the KVM clock mess, part 2 David Woodhouse
2026-11-09  1:20 ` [PATCH v12 01/24] KVM: x86: Improve synchronization in kvm_synchronize_tsc() David Woodhouse
2026-11-09  1:20 ` [PATCH v12 02/24] KVM: x86: Kill last_tsc_{nsec,write,offset} fields David Woodhouse
2026-11-09  1:20 ` [PATCH v12 03/24] KVM: x86: Replace nr_vcpus_matched_tsc count with all_vcpus_matched_tsc bool David Woodhouse
2026-11-09  1:53   ` sashiko-bot
2026-11-09  1:20 ` [PATCH v12 04/24] KVM: x86: Allow KVM master clock mode when TSCs are offset from each other David Woodhouse
2026-11-09  1:45   ` sashiko-bot
2026-11-09  1:20 ` [PATCH v12 05/24] KVM: x86: Factor out kvm_use_master_clock() David Woodhouse
2026-11-09  1:20 ` [PATCH v12 06/24] KVM: x86: Avoid gratuitous global clock updates David Woodhouse
2026-11-09  1:20 ` [PATCH v12 07/24] KVM: x86: Avoid redundant masterclock updates from multiple vCPUs David Woodhouse
2026-11-09  1:53   ` sashiko-bot
2026-11-09  1:20 ` [PATCH v12 08/24] KVM: x86: Re-synchronize TSC after KVM_SET_TSC_KHZ David Woodhouse
2026-11-09  1:53   ` sashiko-bot
2026-11-09  6:24   ` kernel test robot
2026-11-10  5:21   ` kernel test robot
2026-11-09  1:20 ` [PATCH v12 09/24] KVM: x86: Cache host vclock_mode for masterclock eligibility checks David Woodhouse
2026-11-09  1:20 ` [PATCH v12 10/24] KVM: x86: Remove pvclock_gtod_data and private timekeeping code David Woodhouse
2026-11-09  1:20 ` [PATCH v12 11/24] KVM: x86: Activate master clock from kvm_arch_init_vm() David Woodhouse
2026-11-09  1:56   ` sashiko-bot
2026-11-09  1:20 ` [PATCH v12 12/24] UAPI: x86: Move pvclock-abi to UAPI for x86 platforms David Woodhouse
2026-11-09  1:20 ` [PATCH v12 13/24] KVM: selftests: Use UAPI pvclock-abi.h in xen_shinfo_test David Woodhouse
2026-11-09  1:21 ` [PATCH v12 14/24] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate KVM clock migration David Woodhouse
2026-11-09  1:53   ` sashiko-bot
2026-11-09  1:21 ` [PATCH v12 15/24] KVM: selftests: Add library helpers for clock and TSC-offset ioctls David Woodhouse
2026-11-09  1:21 ` [PATCH v12 16/24] KVM: x86: Add KVM_VCPU_TSC_SCALE and fix the documentation on TSC migration David Woodhouse
2026-11-09  1:44   ` sashiko-bot
2026-11-09  1:21 ` [PATCH v12 17/24] KVM: selftests: Add KVM/PV clock selftest to prove timer correction David Woodhouse
2026-11-09  1:21 ` [PATCH v12 18/24] KVM: selftests: Add master clock offset test David Woodhouse
2026-11-09  1:47   ` sashiko-bot [this message]
2026-11-09  1:21 ` [PATCH v12 19/24] KVM: selftests: Add Xen/generic CPUID timing leaf test David Woodhouse
2026-11-09  1:21 ` [PATCH v12 20/24] KVM: selftests: Add Xen runstate migration test David Woodhouse
2026-11-09  1:21 ` [PATCH v12 21/24] KVM: selftests: Test that the first user TSC write is honoured exactly David Woodhouse
2026-11-09  1:21 ` [PATCH v12 22/24] KVM: x86/xen: Drop open-coded fallback clock read in kvm_xen_start_timer() David Woodhouse
2026-11-09  1:21 ` [PATCH v12 23/24] KVM: x86: Use a single time snapshot in kvm_vm_ioctl_set_clock() David Woodhouse
2026-11-09  1:21 ` [PATCH v12 24/24] KVM: x86: Keep master clock for guests using legacy MSR_KVM_SYSTEM_TIME David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-204320@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dwmw2@infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox