[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: |
Fri, 19 Mar 2021 13:02:55 +0100 |
Paolo Bonzini <pbonzini@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
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