[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 3/3] i386: Make sure kvm_arch_set_tsc_khz() succeeds on migra
From: |
Vitaly Kuznetsov |
Subject: |
Re: [PATCH 3/3] i386: Make sure kvm_arch_set_tsc_khz() succeeds on migration when 'hv-reenlightenment' was exposed |
Date: |
Thu, 18 Mar 2021 17:38:00 +0100 |
Paolo Bonzini <pbonzini@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 <vkuznets@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
Re: [PATCH 3/3] i386: Make sure kvm_arch_set_tsc_khz() succeeds on migration when 'hv-reenlightenment' was exposed, Dr. David Alan Gilbert, 2021/03/18
[PATCH 1/3] i386: Make Hyper-V related sections KVM only, Vitaly Kuznetsov, 2021/03/18
[PATCH 2/3] i386: Fix 'hypercall_hypercall' typo, Vitaly Kuznetsov, 2021/03/18