On Thu, Jul 07, 2022, Simon Veith wrote: > With the previous commit having added a KVM clock time reference to Moot point if the two patches are squashed, but avoid "previous commit" and "next commit" and instead use less precise language, e.g. "Now that TSC synchronization can account for a KVM clock time reference, blah blah blah". > kvm_synchronize_tsc(), this patch adds a new TSC attribute Don't use "this patch", the reader knows it's a patch. Just state what's being done in imperative mood, a.d. "add a pair of ioctls to allow getting and setting ..." > KVM_VCPU_TSC_VALUE that allows for setting the TSC value in a way that > is unaffected by scheduling delays. > > Userspace provides a struct kvm_vcpu_tsc_value consisting of a matched > pair of ( guest TSC value, KVM clock value ). The TSC value that will > ultimately be written is adjusted to account for the time which has > elapsed since the given KVM clock time point. > > In order to allow userspace to retrieve an accurate time reference > atomically, without being affected by scheduling delays between > KVM_GET_CLOCK and KVM_GET_MSRS, the KVM_GET_DEVICE_ATTR implementation > for this attribute uses get_kvmclock() internally and returns a struct > kvm_vcpu_tsc_value with both values in one go. If get_kvmclock() > supports the KVM_CLOCK_HOST_TSC flag, the two will be based on one and > the same host TSC reading. > > Signed-off-by: Simon Veith <sveith@xxxxxxxxx> > ---
