Re: [PATCH v7 17/36] KVM: x86: Allow KVM master clock mode when TSCs are offset from each other

On Tue, Aug 11, 2026, David Woodhouse wrote:
> On Tue, 2026-08-11 at 14:46 -0700, Sean Christopherson wrote:
> > On Tue, Aug 11, 2026, David Woodhouse wrote:
> > > On Tue, 2026-08-11 at 11:41 -0700, Sean Christopherson wrote:
> > > 
> > > > 
> > > > Ok, I think I finally understand the goal.  I got turned around by the combination
> > > > of the name SET_CLOCK_GUEST and the full pvclock structure being passed to the
> > > > guest.  I was expecting SET_CLOCK_GUEST to literally set the entire clock, e.g.
> > > > mul+shift, timestamp, etc.
> > > 
> > > That's an implementation detail. 
> > 
> > Yes and no.  If the payload didn't literally have all the assets needed to set
> > the kvmclock fields, then I wouldn't care.  But I don't think I'd be the only
> > person to see a GET+SET pair and expect GET to return exactly what was written
> > via SET.
> 
> Sure, but right now, even a sequence of GET+GET+GET won't necessarily return
> the same answer three times in a row — not just because we haven't fully
> eliminated the non-masterclock mode (which we might never do) but because the
> masterclock mode itself isn't truly the first-class citizen — so we have to
> kind of reverse-engineer it into the per-VM clock data, and then build each
> vCPU's pvclock back out of that again.

True.

> We *ought* to live in a world where that pvclock information *is* the
> canonical source of truth, and any series of GET/SET/GET/GET/SET should never
> see it change. And we can build our future-looking API around that model.
> 
> I think I do stand by my claim that SET/GET/GET potentially having *three*
> slightly different sets of data is an implementation detail that we will
> strive to eliminate.

I'm not totally opposed to a broader GET, but we should definitely get Paolo's
eyes on this sooner than later.