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

[Sean Christopherson <seanjc@google.com>]

On Wed, Aug 05, 2026, David Woodhouse wrote:
> On Wed, 2026-08-05 at 00:06 +0000, sashiko-bot@kernel.org 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 :)

LOL.

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

Roger that, I'll update for v9.

> 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/amPW1eAPpUuxLoj_@google.com/
> ² https://lore.kernel.org/all/58c5a521b94e8d90e101602cfe160d1fb128a5dd.camel@infradead.org/
> ³ https://lore.kernel.org/all/20260728144954.355376-29-dwmw2@infradead.org/