Paolo Bonzini <pbonz...@redhat.com> writes: > On 19/03/21 10:41, Vitaly Kuznetsov wrote: >>> What I want to achieve is to forbid migration of VMs with >>> reenlightenment, if they don't also specify tsc-khz to the frequency of >>> the TSC on the source host. We can't check it at the beginning of >>> migration, but at least we can check it at the end. >>> >>> Maybe we're talking about two different things? >> No, your suggestion basically extends mine and I'm just trying to >> understand the benefit. With my suggestion, it is not required to >> specify tsc-khz on the source, we just take 'native' tsc frequency as a >> reference. Post-migration, we require that KVM_SET_TSC_KHZ succeeds (and >> not just 'try' like kvm_arch_put_registers() does so we effectively >> break migration when we are unable to set the desired TSC frequency >> (also at the end). > > Oh, okay, I understand the confusion; I was thinking of checking for > user_tsc_khz in the post-load function for reenlightenment, not in the > command line processing.
Got it, yes, we can avoid this additional vmstate section and just add a .post_load() hook to the existing vmstate_msr_hyperv_reenlightenment. This will make 'tsc-frequency=' command line option mandatory for successful migration with reenlightenment. Let me draft an alternative patch. -- Vitaly
