From: Peter Xu <peterx@redhat.com>
To: Wei Wang <wei.w.wang@intel.com>
Cc: pbonzini@redhat.com, mtosatti@redhat.com, farosas@suse.de,
qemu-devel@nongnu.org, "Lei Wang" <lei4.wang@intel.com>,
"Jiri Denemark" <jdenemar@redhat.com>,
"Daniel P. Berrangé" <berrange@redhat.com>
Subject: Re: [PATCH v1] target/i386: kvm: Block migration when enfore_cpuid is set to false
Date: Wed, 3 Jul 2024 14:03:33 -0400 [thread overview]
Message-ID: <ZoWSdR1IOQ0iIxZC@x1n> (raw)
In-Reply-To: <20240703144912.130988-1-wei.w.wang@intel.com>
On Wed, Jul 03, 2024 at 10:49:12PM +0800, Wei Wang wrote:
> When enforce_cpuid is set to false, the guest is launched with a filtered
> set of features, meaning that unsupported features by the host are removed
> from the guest's vCPU model. This could cause issues for live migration.
> For example, a guest on the source is running with features A and B. If
> the destination host does not support feature B, the stub guest can still
> be launched on the destination with feature A only if enforce_cpuid=false.
> Live migration can start in this case, though it may fail later when the
> states of feature B are put to the destination side. This failure occurs
> in the late stage (i.e., stop© phase) of the migration flow, where the
> source guest has already been paused. Tests show that in such cases the
> source guest does not recover, and the destination is unable to resume to
> run.
>
> Make "enfore_cpuid=true" a hard requirement for a guest to be migratable,
> and change the default value of "enforce_cpuid" to true, making the guest
> vCPUs migratable by default. If the destination stub guest has inconsistent
> CPUIDs (i.e., destination host cannot support the features defined by the
> guest's vCPU model), it fails to boot (with enfore_cpuid=true by default),
> thereby preventing migration from occuring. If enfore_cpuid=false is
> explicitly added for the guest, the guest is deemed as non-migratable
> (via the migration blocker), so the above issue won't occur as the guest
> won't be migrated.
>
> Tested-by: Lei Wang <lei4.wang@intel.com>
> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
[Copy Jiri and Dan for libvirt-side implications]
> ---
> target/i386/cpu.c | 2 +-
> target/i386/kvm/kvm.c | 25 +++++++++++++++----------
> 2 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/target/i386/cpu.c b/target/i386/cpu.c
> index 4c2e6f3a71..7db4fe4ead 100644
> --- a/target/i386/cpu.c
> +++ b/target/i386/cpu.c
> @@ -8258,7 +8258,7 @@ static Property x86_cpu_properties[] = {
> DEFINE_PROP_UINT32("hv-version-id-snumber", X86CPU, hyperv_ver_id_sn, 0),
>
> DEFINE_PROP_BOOL("check", X86CPU, check_cpuid, true),
> - DEFINE_PROP_BOOL("enforce", X86CPU, enforce_cpuid, false),
> + DEFINE_PROP_BOOL("enforce", X86CPU, enforce_cpuid, true),
I assume in many cases people can still properly migrate when the hosts are
similar or identical, so maybe we at least want the old machine types keep
working (by introducing a machine compat property)?
> DEFINE_PROP_BOOL("x-force-features", X86CPU, force_features, false),
> DEFINE_PROP_BOOL("kvm", X86CPU, expose_kvm, true),
> DEFINE_PROP_UINT32("phys-bits", X86CPU, phys_bits, 0),
> diff --git a/target/i386/kvm/kvm.c b/target/i386/kvm/kvm.c
> index dd8b0f3313..aee717c1cf 100644
> --- a/target/i386/kvm/kvm.c
> +++ b/target/i386/kvm/kvm.c
> @@ -1741,7 +1741,7 @@ static int hyperv_init_vcpu(X86CPU *cpu)
> return 0;
> }
>
> -static Error *invtsc_mig_blocker;
> +static Error *cpu_mig_blocker;
>
> #define KVM_MAX_CPUID_ENTRIES 100
>
> @@ -2012,6 +2012,15 @@ full:
> abort();
> }
>
> +static bool kvm_vcpu_need_block_migration(X86CPU *cpu)
> +{
> + CPUX86State *env = &cpu->env;
> +
> + return !cpu->enforce_cpuid ||
> + (!env->user_tsc_khz && (env->features[FEAT_8000_0007_EDX] &
> + CPUID_APM_INVTSC));
> +}
Nit: maybe it's nice this returns a "const char*" with detailed reasons to
be put into the error_setg(), so it dumps the same as before for the invtsc
blocker.
Thanks,
> +
> int kvm_arch_init_vcpu(CPUState *cs)
> {
> struct {
> @@ -2248,18 +2257,14 @@ int kvm_arch_init_vcpu(CPUState *cs)
> has_msr_mcg_ext_ctl = has_msr_feature_control = true;
> }
>
> - if (!env->user_tsc_khz) {
> - if ((env->features[FEAT_8000_0007_EDX] & CPUID_APM_INVTSC) &&
> - invtsc_mig_blocker == NULL) {
> - error_setg(&invtsc_mig_blocker,
> - "State blocked by non-migratable CPU device"
> - " (invtsc flag)");
> - r = migrate_add_blocker(&invtsc_mig_blocker, &local_err);
> + if (!cpu_mig_blocker && kvm_vcpu_need_block_migration(cpu)) {
> + error_setg(&cpu_mig_blocker,
> + "State blocked by non-migratable CPU device");
> + r = migrate_add_blocker(&cpu_mig_blocker, &local_err);
> if (r < 0) {
> error_report_err(local_err);
> return r;
> }
> - }
> }
>
> if (cpu->vmware_cpuid_freq
> @@ -2312,7 +2317,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
> return 0;
>
> fail:
> - migrate_del_blocker(&invtsc_mig_blocker);
> + migrate_del_blocker(&cpu_mig_blocker);
>
> return r;
> }
> --
> 2.27.0
>
>
--
Peter Xu
next prev parent reply other threads:[~2024-07-03 18:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-03 14:49 [PATCH v1] target/i386: kvm: Block migration when enfore_cpuid is set to false Wei Wang
2024-07-03 18:03 ` Peter Xu [this message]
2024-07-04 15:10 ` Wang, Wei W
2024-07-04 15:59 ` Peter Xu
2024-07-05 10:22 ` Wang, Wei W
2024-07-05 13:34 ` Peter Xu
2024-07-11 11:40 ` Wang, Wei W
2024-07-11 11:47 ` Daniel P. Berrangé
2024-07-11 12:10 ` Wang, Wei W
2024-07-11 12:24 ` Daniel P. Berrangé
2024-07-11 13:48 ` Wang, Wei W
2024-07-11 13:56 ` Daniel P. Berrangé
2024-07-11 14:13 ` Wang, Wei W
2024-07-11 14:14 ` Daniel P. Berrangé
2024-07-11 15:09 ` Wang, Wei W
2024-07-11 15:45 ` Daniel P. Berrangé
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=ZoWSdR1IOQ0iIxZC@x1n \
--to=peterx@redhat.com \
--cc=berrange@redhat.com \
--cc=farosas@suse.de \
--cc=jdenemar@redhat.com \
--cc=lei4.wang@intel.com \
--cc=mtosatti@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wei.w.wang@intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).