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!
smime.p7s
Description: S/MIME cryptographic signature
