From nobody Wed Jun 24 21:41:35 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) client-ip=38.145.34.151; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=reject dis=none) header.from=lists.libvirt.org ARC-Seal: i=1; a=rsa-sha256; t=1781857593; cv=none; d=zohomail.com; s=zohoarc; b=R5NovTqXnsaC0uPLsmcr91K2Eeo8xqBjST9k6TRHaqDRWIsQOZh7E895//Xqe35Z5giS8ZFAeV8eY72P5BtOefYSvd2jlNXaK1WG9MUhCO1zc79KtHp1dN2au9Ij58R+eI7ACGYGdv9RbDJNtJJq2BcKQEgtviKYq0oYUYMDVYM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1781857593; h=Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:Subject:Subject:To:To:Message-Id; bh=ZcUf+83nXCR8J0HC5tlU/FBG3I4pghKB2dd5JOsd54Y=; b=V5Ajne0ZtZT2Naze4VgR0oqklOshY1udzzJcqxg0k7rkX1Qrzfwzm9KupvCDbdM3tffBibwLB+I7+PBkeZQFb3D5PTzNB+WshmGeNF021g05t6E6u6+EwMbCDrwylxtrvw/KV1Af3Qc5BWVTBr/AbdjbtBNVFIzSoYAAu5v4Q6c= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 38.145.34.151 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [38.145.34.151]) by mx.zohomail.com with SMTPS id 1781857593082280.69690760958474; Fri, 19 Jun 2026 01:26:33 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 993) id 6C13F41CA9; Fri, 19 Jun 2026 04:26:30 -0400 (EDT) Received: from [172.19.199.7] (unknown [10.16.107.18]) by lists.libvirt.org (Postfix) with ESMTP id 5EDC241D60; Fri, 19 Jun 2026 04:25:33 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 993) id F03EB41A0C; Thu, 18 Jun 2026 10:51:55 -0400 (EDT) Received: from relay.virtuozzo.com (relay.virtuozzo.com [130.117.225.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (3072 bits) server-digest SHA256) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id C897741D32 for ; Thu, 18 Jun 2026 10:51:54 -0400 (EDT) Received: from ch-demo-asa.virtuozzo.com ([130.117.225.8] helo=athena.sw.ru) by relay.virtuozzo.com with esmtp (Exim 4.96) (envelope-from ) id 1waE5M-00APQF-0P; Thu, 18 Jun 2026 16:51:47 +0200 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=4.0.1 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=virtuozzo.com; s=relay; h=MIME-Version:Message-ID:Date:Subject:From: Content-Type; bh=ZcUf+83nXCR8J0HC5tlU/FBG3I4pghKB2dd5JOsd54Y=; b=lF5ePxPljvV4 goz79pxrwQW8RWyT0l0OB8oaaDe+NFs5c+jPT/ZEdYxFsRY/kTVX9SswkgKCw8D4Afn2x+j0ZQJdp ELvtsBuhS3Km+AvDmkXh2qQ/O1LD+qLMKh0MlvbsoozFrey5AcjBlSStTYlWtb9mClZWXTyXCotuN TnYu0u5vOLpALY5fvbpeIVtkU51A0acEoJ92ZmDFnDoFN3JVNGpD1K573tq780wMr2TBeEhhBWwVU eF6CB/P7Ri7zRue44IqyTrmEZwPqNKgZzi3PPFvGA40riB/ZdPy8Eizx7tTEt4eLdfK8oCyPoy4ep GML6R8IP7u1oRZH+0gb7gw==; To: devel@lists.libvirt.org Subject: [PATCH v2] qemu: stop silently narrowing the guest CPU during live migration Date: Thu, 18 Jun 2026 16:51:49 +0200 Message-ID: <20260618145149.3442151-1-den@openvz.org> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-MailFrom: den@openvz.org X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.lists.libvirt.org-0; emergency; member-moderation Message-ID-Hash: KGPIYM5QON7H44FXGMDZEW5LDNI3NEWX X-Message-ID-Hash: KGPIYM5QON7H44FXGMDZEW5LDNI3NEWX X-Mailman-Approved-At: Fri, 19 Jun 2026 08:25:25 +0000 CC: den@openvz.org X-Mailman-Version: 3.3.10 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "Denis V. Lunev via Devel" Reply-To: "Denis V. Lunev" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1781857598459158500 Content-Type: text/plain; charset="utf-8" qemuDomainMakeCPUMigratable() strips the features that a CPU model marks as added (in src/cpu_map/x86_*.xml) from the migratable definition unless the user requested them explicitly. This keeps a custom CPU migratable to an older destination libvirt whose copy of the model does not know those features yet. A host-model CPU gains nothing from this and is actively harmed by it. By the time it reaches this function host-model has already been expanded into an explicit custom model that is exactly what we ask QEMU for on the source, and host-model is not guaranteed to migrate to an older libvirt in the first place. Stripping the added features only narrows the guest CPU silently on the destination. Every Intel model from Westmere through Sapphire Rapids marks vmx-exit-load-perf-global-ctrl and vmx-entry-load-perf-global-ctrl as added. These control the LOAD_IA32_PERF_GLOBAL_CTRL allowed-1 bits of the MSR_IA32_VMX_{EXIT,ENTRY}_CTLS MSRs, which modern QEMU only advertises when the features are present on the -cpu command line. After a host-model live migration the destination QEMU is started without them, so a nested guest observes different VMX capability MSRs than it did before the migration. A guest that snapshots those MSRs at kvm_intel module load and validates every newly onlined CPU against the snapshot -- Linux does exactly that -- then refuses to bring up a vCPU hot-plugged after the migration: kvm_intel: Inconsistent VMCS config on CPU N kvm: enabling virtualization on CPUN failed smpboot: CPU N is now offline and the guest agent's online attempt returns -EIO. Treat a host-model CPU's features as explicitly requested by building the keep list from the already expanded definition rather than from origCPU. Custom CPUs are unaffected, so their migration compatibility with older destinations is preserved. Signed-off-by: Denis V. Lunev Reviewed-by: Jiri Denemark --- v1 -> v2: instead of dropping the added-feature stripping altogether (v1), keep it and only stop applying it to a host-model CPU. Custom CPUs still rely on the stripping to stay migratable to an older destination libvirt, which v1 regressed. src/qemu/qemu_domain.c | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index a43a5c0e4f..e1b805d906 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -5373,12 +5373,18 @@ qemuDomainMakeCPUMigratable(virArch arch, if (virCPUx86GetAddedFeatures(cpu->model, &data.added) < 0) return -1; =20 - /* Drop features marked as added in a cpu model, but only - * when they are not mentioned in origCPU, i.e., when they were not - * explicitly mentioned by the user. - */ + /* Drop features marked as added in a CPU model unless they were + * explicitly requested, so the migratable definition stays + * compatible with destinations that do not know them. For host-mo= del + * the expanded definition is itself the requested CPU, so keep al= l of + * its features; for a custom CPU keep only those listed in origCP= U. */ if (data.added) { - g_auto(GStrv) keep =3D virCPUDefListExplicitFeatures(origCPU); + g_auto(GStrv) keep =3D NULL; + + if (origCPU->mode =3D=3D VIR_CPU_MODE_HOST_MODEL) + keep =3D virCPUDefListExplicitFeatures(cpu); + else + keep =3D virCPUDefListExplicitFeatures(origCPU); data.keep =3D keep; =20 virCPUDefFilterFeatures(cpu, qemuDomainDropAddedCPUFeatures, &= data); --=20 2.53.0