On Mon, Aug 16, 2021 at 12:11:25AM +0000, Oliver Upton wrote: > Sean noticed that KVM_GET_CLOCK was checking kvm_arch.use_master_clock > outside of the pvclock sync lock. This is problematic, as the clock > value written to the user may or may not actually correspond to a stable > TSC. > > Fix the race by populating the entire kvm_clock_data structure behind > the pvclock_gtod_sync_lock. Oliver, Can you please describe the race in more detail? Is it about host TSC going unstable VS parallel KVM_GET_CLOCK ?
