Re: [PATCH v8 04/17] KVM: x86: Activate master clock immediately on vCPU creation

On Wed, 2026-08-05 at 00:06 +0000, [email protected] wrote:
> [Severity: High]
> Instead of checking the boolean use_master_clock, should this check and
> consume the pending KVM_REQ_MASTERCLOCK_UPDATE request via kvm_check_request?

Oh, all right then :)

Sean suggested exactly that in a previous round¹ and I said I thought
I'd tried it and the request wasn't set. Having paged back in some of
that context... the thing which didn't work was a different variant —
deferring with a bare kvm_make_request()², which fails because
KVM_GET_CLOCK doesn't process vCPU requests, so calling it before the
first KVM_RUN still didn't work. That isn't what's being suggested
here.

With the code as it stands in this series, the first vCPU's
kvm_synchronize_tsc() reliably queues KVM_REQ_MASTERCLOCK_UPDATE via
the use_master_clock toggle in kvm_track_tsc_matching(). So

	if (kvm_check_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu))
		kvm_update_masterclock(vcpu->kvm);

should work, and is better than checking the boolean: it avoids the
repeated masterclock update that Sashiko is whining about, while still
honouring the case where a mismatched new vCPU should *disable* the
master clock.

By the end of my full series, this call gets removed entirely in favour
of setting up the whole clock epoch from kvm_arch_init_vm()³, which is
why I didn't care much before. But that's now on the far side of the
part 1 / part 2 split, so it's worth fixing here.

¹ https://lore.kernel.org/all/[email protected]/
² https://lore.kernel.org/all/[email protected]/
³ https://lore.kernel.org/all/[email protected]/