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

[Sean Christopherson <seanjc@google.com>]

On Sat, Jul 25, 2026, David Woodhouse wrote:
> On Fri, 2026-07-24 at 14:17 -0700, Sean Christopherson wrote:
> > Please post this as a standalone mini-series.  AFAICT, the only dependency of
> > any kind is a minor conflict with the s/hw_tsc_khz/hw_tsc_hz change, and that's
> > trivial to sort out later on.
> 
> Hm? The calculations in kvm_vcpu_ioctl_set_clock_guest() are all Hz-
> based, not kHz. This *was* the start of the series (Jack posted it on
> its own in 2024), and I thought I'd moved the khz/hz thing to live
> before it on purpose?
> 
> The kvm_xen_shared_info_init() one could be later, I guess. But is also
> trivial (and its commit message sets the stage for a bunch of the
> cleanups by analysing the various *different* ways that kvmclock gets
> derived). 
> 
> I confess I'm not stunningly keen on breaking the series up.

Can the KVM_[GS]ET_CLOCK_GUEST changes be moved to the end of the series?  The
total size of the series doesn't scare me, I just don't want to end up with all
the fixes and cleanups stuck behind a patch that isn't a hard dependency.  E.g.
AFAICT, none of the following changes, include selftests updates, actualy rely
on KVM_[GS]ET_CLOCK_GUEST existing.

> How about we just do it in stages? Merge patch 1 as it's fairly trivial, 

Ya, I pushed that to kvm-x86 last week, though I rebased it today because of an
unrelated goof.  It's currently commit 710b3a30f407 ("KVM: x86/xen: Do not corrupt
KVM clock in kvm_xen_shared_info_init()").  If nothing blows up in the next or two,
that should be the stable hash going forward.

> and then I can use its commit ID when I refer to its taxonomy later. Then we
> can do patches 2-6 which are the KVM_[GS]ET_CLOCK_GUEST support. And I can
> repost the remainder on top of that?
> 
> > > +4.145 KVM_GET_CLOCK_GUEST
> > > +----------------------------
> > > +
> > > +:Capability: none
> > 
> > Why not add a CAP?  The check in the subsequent selftest is quite gross.
> 
> Because nobody would ever use it in practice anyway. Even if the ioctl
> is present, you *still* have to try it and fall back to the old method
> because there are ways that a *guest* can force master clock mode off.

Hmm, I can see setups where a single entity controls both the host and the guest
wanting to assert that KVM_SET_CLOCK_GUEST succeeds, though I suppose it's
unlikely such setups would use KVM_SET_CLOCK_GUEST in the first place.