On 1/20/23 02:06, Marcelo Tosatti wrote:
Before commit 78db6a5037965429c04d708281f35a6e5562d31b, kvm_guest_time_update() would use vcpu->virtual_tsc_khz to calculate tsc_shift value in the vcpus pvclock structure written to guest memory. For those kernels, if vcpu->virtual_tsc_khz != tsc_khz (which can be the case when guest state is restored via migration, or if tsc-khz option is passed to QEMU), and TSC scaling is not enabled (which happens if the difference between the frequency requested via KVM_SET_TSC_KHZ and the host TSC KHZ is smaller than 250ppm), then there can be a difference between what KVM_GET_CLOCK would return and what the guest reads as kvmclock value.
I don't think it's justifiable to further complicate the userspace API for a bug that's been fixed six years ago. I'd be very surprised if any combination of modern upstream {QEMU,kernel} is going to do a successful migration from such an old {QEMU,kernel}. RHEL/CentOS are able to do so because *specific pairs* have been tested, but as far as upstream is concerned this adds complexity that absolutely no one will use.
I replied on the QEMU patch with further suggestions. Paolo
