Paolo Bonzini <pbonz...@redhat.com> writes: > On 18/03/21 17:02, Vitaly Kuznetsov wrote: >> KVM doesn't fully support Hyper-V reenlightenment notifications on >> migration. In particular, it doesn't support emulating TSC frequency >> of the source host by trapping all TSC accesses so unless TSC scaling >> is supported on the destination host and KVM_SET_TSC_KHZ succeeds, it >> is unsafe to proceed with migration. >> >> Normally, we only require KVM_SET_TSC_KHZ to succeed when 'user_tsc_khz' >> was set and just 'try' KVM_SET_TSC_KHZ without otherwise. >> >> Introduce a new vmstate section (which is added when the guest has >> reenlightenment feature enabled) and add env.tsc_khz to it. We already >> have env.tsc_khz packed in 'cpu/tsc_khz' but we don't want to be dependent >> on the section order. >> >> Signed-off-by: Vitaly Kuznetsov <vkuzn...@redhat.com> > > Could we instead fail to load the reenlightenment section if > user_tsc_khz was not set? This seems to be user (well, management) > error really, since reenlightenment has to be enabled manually (or with > hv-passthrough which blocks migration too).
Yes, we certainly could do that but what's the added value of user_tsc_khz which upper layer will have to set explicitly (probably to the tsc frequency of the source host anyway)? In case we just want to avoid calling KVM_SET_TSC_KHZ twice, we can probably achieve that by adding a CPU flag or something. -- Vitaly