From: David Woodhouse <dwmw@amazon.co.uk>

Previously, the master clock was only activated when the first vCPU
processed KVM_REQ_MASTERCLOCK_UPDATE during KVM_RUN. This meant that
KVM_GET_CLOCK could not return the host_tsc field until after the
first KVM_RUN, making it impossible for userspace to follow the
documented TSC migration procedure without a dummy vCPU run.

Fix this by calling kvm_update_masterclock() directly from
kvm_arch_vcpu_postcreate(), after kvm_synchronize_tsc() has already
set all_vcpus_matched_freq. This ensures the master clock is active
immediately, and KVM_GET_CLOCK returns a valid {host_tsc, realtime}
pair as soon as a vCPU exists.

Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 arch/x86/kvm/x86.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index ff45577ed90c..2039bd8518fb 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -13110,6 +13110,8 @@ void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
 		return;
 	vcpu_load(vcpu);
 	kvm_synchronize_tsc(vcpu, NULL);
+	if (!vcpu->kvm->arch.use_master_clock)
+		kvm_update_masterclock(vcpu->kvm);
 	vcpu_put(vcpu);
 
 	/* poll control enabled by default */
-- 
2.54.0

On Fri, Jul 03, 2026, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> Previously, the master clock was only activated when the first vCPU
> processed KVM_REQ_MASTERCLOCK_UPDATE during KVM_RUN. This meant that
> KVM_GET_CLOCK could not return the host_tsc field until after the
> first KVM_RUN, making it impossible for userspace to follow the
> documented TSC migration procedure without a dummy vCPU run.
> 
> Fix this by calling kvm_update_masterclock() directly from
> kvm_arch_vcpu_postcreate(), after kvm_synchronize_tsc() has already
> set all_vcpus_matched_freq. This ensures the master clock is active
> immediately, and KVM_GET_CLOCK returns a valid {host_tsc, realtime}
> pair as soon as a vCPU exists.
> 
> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> ---
>  arch/x86/kvm/x86.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index ff45577ed90c..2039bd8518fb 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -13110,6 +13110,8 @@ void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
>  		return;
>  	vcpu_load(vcpu);
>  	kvm_synchronize_tsc(vcpu, NULL);
> +	if (!vcpu->kvm->arch.use_master_clock)

Any reason this can't be?

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

> +		kvm_update_masterclock(vcpu->kvm);

I don't love doing work outside of KVM_RUN that is typically handled by KVM_RUN,
but this seems fine?

>  	vcpu_put(vcpu);
>  
>  	/* poll control enabled by default */
> -- 
> 2.54.0
>

On Fri, 2026-07-24 at 14:19 -0700, Sean Christopherson wrote:
> On Fri, Jul 03, 2026, David Woodhouse wrote:
> > From: David Woodhouse <dwmw@amazon.co.uk>
> > 
> > Previously, the master clock was only activated when the first vCPU
> > processed KVM_REQ_MASTERCLOCK_UPDATE during KVM_RUN. This meant that
> > KVM_GET_CLOCK could not return the host_tsc field until after the
> > first KVM_RUN, making it impossible for userspace to follow the
> > documented TSC migration procedure without a dummy vCPU run.
> > 
> > Fix this by calling kvm_update_masterclock() directly from
> > kvm_arch_vcpu_postcreate(), after kvm_synchronize_tsc() has already
> > set all_vcpus_matched_freq. This ensures the master clock is active
> > immediately, and KVM_GET_CLOCK returns a valid {host_tsc, realtime}
> > pair as soon as a vCPU exists.
> > 
> > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
> > ---
> >   arch/x86/kvm/x86.c | 2 ++
> >   1 file changed, 2 insertions(+)
> > 
> > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> > index ff45577ed90c..2039bd8518fb 100644
> > --- a/arch/x86/kvm/x86.c
> > +++ b/arch/x86/kvm/x86.c
> > @@ -13110,6 +13110,8 @@ void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
> >   		return;
> >   	vcpu_load(vcpu);
> >   	kvm_synchronize_tsc(vcpu, NULL);
> > +	if (!vcpu->kvm->arch.use_master_clock)
> 
> Any reason this can't be?
> 
> 	if (kvm_check_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu))
> 		kvm_update_masterclock(vcpu->kvm);
> 
> > +		kvm_update_masterclock(vcpu->kvm);
> 
> I don't love doing work outside of KVM_RUN that is typically handled by KVM_RUN,
> but this seems fine?

I think I tried that first and it didn't work because
KVM_REQ_MASTERCLOCK_UPDATE wasn't actually set yet. I remember going
round in circles a few times here. I'll take another look.

On Sat, 2026-07-25 at 08:59 +0100, David Woodhouse wrote:
> 
> > Any reason this can't be?
> > 
> >  	if (kvm_check_request(KVM_REQ_MASTERCLOCK_UPDATE, vcpu))
> >  		kvm_update_masterclock(vcpu->kvm);
> > 
> > > +		kvm_update_masterclock(vcpu->kvm);
> > 
> > I don't love doing work outside of KVM_RUN that is typically handled by KVM_RUN,
> > but this seems fine?
> 
> I think I tried that first and it didn't work because
> KVM_REQ_MASTERCLOCK_UPDATE wasn't actually set yet. I remember going
> round in circles a few times here. I'll take another look.
> 

On the other hand... I rip it out in patch 36 anyway, in favour of the
cleaner answer that is available once I've cleaned up the rest of the
masterclock stuff.

But I wanted this to be earlier in the series as it does fix things for
the selftests which get introduced along the way. Otherwise we have to
run the vCPU once to set the clocks up.