Re: [PATCH v7 31/36] KVM: x86: Add KVM_[GS]ET_CLOCK_GUEST for accurate KVM clock migration

[Sean Christopherson <seanjc@google.com>]

On Tue, Jul 28, 2026, David Woodhouse wrote:
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 5c78dd1e4c69..0680332d7d45 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -3435,6 +3435,169 @@ 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_vcpu_arch *vcpu = &v->arch;
> +	struct kvm_arch *ka = &v->kvm->arch;
> +	unsigned int seq;
> +
> +	/*
> +	 * If KVM_REQ_CLOCK_UPDATE is already pending, or if the pvclock
> +	 * has never been generated at all, call kvm_guest_time_update().
> +	 */
> +	if (kvm_check_request(KVM_REQ_CLOCK_UPDATE, v) || !vcpu->hw_tsc_hz) {
> +		int idx = srcu_read_lock(&v->kvm->srcu);
> +		int ret = kvm_guest_time_update(v);

Invoking kvm_guest_time_update() here is probably a deal-breaker.  Updating the
master clock and other internal state is far from ideal, but should be ok.

However, writing guest memory is not.  Specifically, dirtying memory after the
last KVM_RUN is a non-starter for many usecases, as is modifying state that is
visible via other GET uAPI (though I don't think that applies here?).  E.g. see
commits:

  118964562969 ("KVM: Mark a vCPU as preempted/ready iff it's scheduled out while running")
  e800decd9c0a ("KVM: x86: Only reset TSC Deadline Timer in apic_timer_expired on KVM_RUN")

One idea would be to simply punt to userspace, i.e. return -EBUSY without trying
to update guest time.  Which is pretty darn ugly, but might be tolerable?  And a
slightly crazy idea to lessen the pain would be to process select requests in
KVM_RUN before bailing for vcpu->run->immediate_exit==true.

That doesn't completely solve things as it's still possible for KVM_REQ_CLOCK_UPDATE
to be set after KVM_RUN, but I think they're mutually exlusive with the majority
of relevant use cases?  And we'd probably want to build on my idea to report that
KVM_RUN needs completion[*], but that'd be a good thing overall.

https://lore.kernel.org/all/20250111012450.1262638-1-seanjc@google.com