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

[David Woodhouse <dwmw2@xxxxxxxxxxxxx>]

On Tue, 2026-08-11 at 16:40 -0700, Sean Christopherson wrote:
> > +
> > +   /*
> > +    * 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:

I don't think we need it written to guest memory; we only need to
generate the in-kernel shadow which is then written to the guest.

I wonder if we can have a boolean 'write_guest' argument to
kvm_guest_time_update() .. but ick.

Or maybe it's OK to just return -EBUSY. Isn't KVM_REQ_CLOCK_UPDATE a
pathological case anyway these day? I'm trying to ignore
kvm_set_guest_paused()... 

I'll take another look in the morning at the whole thing.

Attachment: smime.p7s
Description: S/MIME cryptographic signature