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.
