[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: |
Marcelo Tosatti |
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 15:03:32 -0300 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
On Thu, Mar 18, 2021 at 05:38:00PM +0100, Vitaly Kuznetsov wrote:
> 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).
Seems to match the strategy of the patchset...
> 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)?
Yes. I think what happened was "evolution":
1) Added support to set tsc frequency (with hardware multiplier)
in KVM, so add -tsc-khz VAL (kHz) option to KVM.
2) Scaling is enabled only if -tsc-khz VAL is supplied.
3) libvirt switches to using -tsc-khz HVAL, where HVAL it retrieves
from KVM_GET_TSC_KHZ of newly created KVM_CREATE_VM instance.
It could have been done inside qemu instead.
> 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.
Avoid calling KVM_SET_TSC_KHZ twice ? Don't see why you would avoid
that.
- [PATCH 0/3] i386: Make sure TSC frequency is preserved across migration when Hyper-V reenlightenment is in use, Vitaly Kuznetsov, 2021/03/18
- [PATCH 3/3] i386: Make sure kvm_arch_set_tsc_khz() succeeds on migration when 'hv-reenlightenment' was exposed, Vitaly Kuznetsov, 2021/03/18
- Re: [PATCH 3/3] i386: Make sure kvm_arch_set_tsc_khz() succeeds on migration when 'hv-reenlightenment' was exposed, Paolo Bonzini, 2021/03/18
- Re: [PATCH 3/3] i386: Make sure kvm_arch_set_tsc_khz() succeeds on migration when 'hv-reenlightenment' was exposed, Vitaly Kuznetsov, 2021/03/18
- Re: [PATCH 3/3] i386: Make sure kvm_arch_set_tsc_khz() succeeds on migration when 'hv-reenlightenment' was exposed, Paolo Bonzini, 2021/03/18
- Re: [PATCH 3/3] i386: Make sure kvm_arch_set_tsc_khz() succeeds on migration when 'hv-reenlightenment' was exposed, Vitaly Kuznetsov, 2021/03/19
- Re: [PATCH 3/3] i386: Make sure kvm_arch_set_tsc_khz() succeeds on migration when 'hv-reenlightenment' was exposed, Paolo Bonzini, 2021/03/19
- Re: [PATCH 3/3] i386: Make sure kvm_arch_set_tsc_khz() succeeds on migration when 'hv-reenlightenment' was exposed, Vitaly Kuznetsov, 2021/03/19
- Re: [PATCH 3/3] i386: Make sure kvm_arch_set_tsc_khz() succeeds on migration when 'hv-reenlightenment' was exposed,
Marcelo Tosatti <=
- Re: [PATCH 3/3] i386: Make sure kvm_arch_set_tsc_khz() succeeds on migration when 'hv-reenlightenment' was exposed, Vitaly Kuznetsov, 2021/03/19
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