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

[David Woodhouse]

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.

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.

And hey, at *least* they genuinely are within single-digit nanoseconds
now!

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