From: Paolo Bonzini <pbonzini@redhat.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>, qemu-devel@nongnu.org
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
Richard Henderson <richard.henderson@linaro.org>,
Eduardo Habkost <ehabkost@redhat.com>,
"Dr . David Alan Gilbert" <dgilbert@redhat.com>
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 18:36:20 +0100 [thread overview]
Message-ID: <104d7d27-48b9-d2f0-213f-54853270bcd6@redhat.com> (raw)
In-Reply-To: <87wnu45sev.fsf@vitty.brq.redhat.com>
On 18/03/21 17:38, Vitaly Kuznetsov wrote:
>> 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.
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?
Paolo
next prev parent reply other threads:[~2021-03-18 17:38 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-18 16:02 [PATCH 0/3] i386: Make sure TSC frequency is preserved across migration when Hyper-V reenlightenment is in use Vitaly Kuznetsov
2021-03-18 16:02 ` [PATCH 1/3] i386: Make Hyper-V related sections KVM only Vitaly Kuznetsov
2021-03-18 16:06 ` Paolo Bonzini
2021-03-18 16:02 ` [PATCH 2/3] i386: Fix 'hypercall_hypercall' typo Vitaly Kuznetsov
2021-03-18 16:12 ` Paolo Bonzini
2021-03-18 16:02 ` [PATCH 3/3] i386: Make sure kvm_arch_set_tsc_khz() succeeds on migration when 'hv-reenlightenment' was exposed Vitaly Kuznetsov
2021-03-18 16:12 ` Paolo Bonzini
2021-03-18 16:38 ` Vitaly Kuznetsov
2021-03-18 17:36 ` Paolo Bonzini [this message]
2021-03-19 9:41 ` Vitaly Kuznetsov
2021-03-19 11:04 ` Paolo Bonzini
2021-03-19 12:02 ` Vitaly Kuznetsov
2021-03-18 18:03 ` Marcelo Tosatti
2021-03-19 9:46 ` Vitaly Kuznetsov
2021-03-18 20:13 ` Dr. David Alan Gilbert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=104d7d27-48b9-d2f0-213f-54853270bcd6@redhat.com \
--to=pbonzini@redhat.com \
--cc=dgilbert@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=vkuznets@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.