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/[email protected]
