From nobody Fri May 17 11:05:26 2024 Delivered-To: importer@patchew.org Received-SPF: none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; spf=none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1713290103905557.8015825103279; Tue, 16 Apr 2024 10:55:03 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 996) id C61031B49; Tue, 16 Apr 2024 13:55:02 -0400 (EDT) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id 7970A1BA2; Tue, 16 Apr 2024 13:53:58 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 996) id ADE311B30; Tue, 16 Apr 2024 13:53:52 -0400 (EDT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 1841A1B30 for ; Tue, 16 Apr 2024 13:53:41 -0400 (EDT) Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-410-zju4kbRZM3Kgbh6djqM7TA-1; Tue, 16 Apr 2024 13:53:38 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1B6671044573 for ; Tue, 16 Apr 2024 17:53:38 +0000 (UTC) Received: from orkuz (unknown [10.45.224.56]) by smtp.corp.redhat.com (Postfix) with ESMTP id D1B921121306 for ; Tue, 16 Apr 2024 17:53:37 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.4 X-MC-Unique: zju4kbRZM3Kgbh6djqM7TA-1 From: Jiri Denemark To: devel@lists.libvirt.org Subject: [PATCH 1/2] qemu: Fix migration with custom XML Date: Tue, 16 Apr 2024 19:53:25 +0200 Message-ID: <45719348dbb95a7c99e8023855d8d81926ddcbd0.1713289982.git.jdenemar@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Message-ID-Hash: JUZ2AEG4KG555T7XYAD3OSCK6R4WP7MV X-Message-ID-Hash: JUZ2AEG4KG555T7XYAD3OSCK6R4WP7MV X-MailFrom: jdenemar@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; header-match-devel.lists.libvirt.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.2 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZM-MESSAGEID: 1713290105061100001 Ages ago origCPU in domain private data was introduced to provide backward compatibility when migrating to an old libvirt, which did not support fetching updated CPU definition from QEMU. Thus origCPU will contain the original CPU definition before such update. But only if the update actually changed anything. Let's always fill origCPU with the original definition when starting a domain so that we can rely on it being always set, even if it matches the updated definition. This fixes migration or save operations with custom domain XML after commit v10.1.0-88-g14d3517410, which expected origCPU to be always set to the CPU definition from inactive XML to check features explicitly requested by a user. https://issues.redhat.com/browse/RHEL-30622 Signed-off-by: Jiri Denemark Tested-by: Han Han --- src/qemu/qemu_domain.c | 38 +++++++++++++++++++++----------------- src/qemu/qemu_process.c | 14 ++------------ 2 files changed, 23 insertions(+), 29 deletions(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 6b869797a8..ca50d435d2 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -10995,12 +10995,13 @@ virSaveCookieCallbacks virQEMUDriverDomainSaveCoo= kie =3D { * @vm: domain which is being started * @cpu: CPU updated when the domain was running previously (before migrat= ion, * snapshot, or save) - * @origCPU: where to store the original CPU from vm->def in case @cpu was - * used instead + * @origCPU: where to store the original CPU from vm->def * - * Replace the CPU definition with the updated one when QEMU is new enough= to - * allow us to check extra features it is about to enable or disable when - * starting a domain. The original CPU is stored in @origCPU. + * Save the original CPU definition from inactive XML in @origCPU so that = we + * can safely update it and still be able to check what exactly a user ask= ed + * for. The domain definition will either contain a copy of the original C= PU + * definition or a copy of @cpu in case the domain was already running and + * we're just restoring a saved state or preparing for incoming migration. * * Returns 0 on success, -1 on error. */ @@ -11013,15 +11014,25 @@ qemuDomainUpdateCPU(virDomainObj *vm, =20 *origCPU =3D NULL; =20 - if (!cpu || !vm->def->cpu || - !virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSIO= N) || - virCPUDefIsEqual(vm->def->cpu, cpu, false)) + if (!vm->def->cpu) return 0; =20 - if (!(cpu =3D virCPUDefCopy(cpu))) + if (!virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_QUERY_CPU_MODEL_EXPANSIO= N)) + return 0; + + /* nothing to do if only topology part of CPU def is used */ + if (vm->def->cpu->mode =3D=3D VIR_CPU_MODE_CUSTOM && !vm->def->cpu->mo= del) + return 0; + + if (cpu) + cpu =3D virCPUDefCopy(cpu); + else + cpu =3D virCPUDefCopy(vm->def->cpu); + + if (!cpu) return -1; =20 - VIR_DEBUG("Replacing CPU def with the updated one"); + VIR_DEBUG("Replacing CPU definition"); =20 *origCPU =3D vm->def->cpu; vm->def->cpu =3D cpu; @@ -11064,13 +11075,6 @@ qemuDomainFixupCPUs(virDomainObj *vm, !vm->def->cpu->model) return 0; =20 - /* Missing origCPU means QEMU created exactly the same virtual CPU whi= ch - * we asked for or libvirt was too old to mess up the translation from - * host-model. - */ - if (!*origCPU) - return 0; - if (virCPUDefFindFeature(vm->def->cpu, "cmt")) { g_autoptr(virCPUDef) fixedCPU =3D virCPUDefCopyWithoutModel(vm->de= f->cpu); =20 diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index e4bcb628cf..8165c28dbc 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -4437,8 +4437,6 @@ qemuProcessUpdateLiveGuestCPU(virDomainObj *vm, virCPUData *disabled) { virDomainDef *def =3D vm->def; - qemuDomainObjPrivate *priv =3D vm->privateData; - g_autoptr(virCPUDef) orig =3D NULL; int rc; =20 if (!enabled) @@ -4449,19 +4447,11 @@ qemuProcessUpdateLiveGuestCPU(virDomainObj *vm, !def->cpu->model)) return 0; =20 - orig =3D virCPUDefCopy(def->cpu); - - if ((rc =3D virCPUUpdateLive(def->os.arch, def->cpu, enabled, disabled= )) < 0) { + if ((rc =3D virCPUUpdateLive(def->os.arch, def->cpu, enabled, disabled= )) < 0) return -1; - } else if (rc =3D=3D 0) { - /* Store the original CPU in priv if QEMU changed it and we didn't - * get the original CPU via migration, restore, or snapshot revert. - */ - if (!priv->origCPU && !virCPUDefIsEqual(def->cpu, orig, false)) - priv->origCPU =3D g_steal_pointer(&orig); =20 + if (rc =3D=3D 0) def->cpu->check =3D VIR_CPU_CHECK_FULL; - } =20 return 0; } --=20 2.44.0 _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org From nobody Fri May 17 11:05:26 2024 Delivered-To: importer@patchew.org Received-SPF: none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; spf=none (zohomail.com: 8.43.85.245 is neither permitted nor denied by domain of lists.libvirt.org) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=fail(p=none dis=none) header.from=redhat.com Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1713290154625583.0897988151572; Tue, 16 Apr 2024 10:55:54 -0700 (PDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 7AD181B2D; Tue, 16 Apr 2024 13:55:53 -0400 (EDT) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id 146881BE4; Tue, 16 Apr 2024 13:54:32 -0400 (EDT) Received: by lists.libvirt.org (Postfix, from userid 996) id 44A431A6F; Tue, 16 Apr 2024 13:54:26 -0400 (EDT) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 4D50D1AF8 for ; Tue, 16 Apr 2024 13:54:02 -0400 (EDT) Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-531-Oh1hnerzNmWeZq57PFf8Nw-1; Tue, 16 Apr 2024 13:53:59 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 90A9A28EC10B for ; Tue, 16 Apr 2024 17:53:59 +0000 (UTC) Received: from orkuz (unknown [10.45.224.56]) by smtp.corp.redhat.com (Postfix) with ESMTP id 25C3F40C6CB2 for ; Tue, 16 Apr 2024 17:53:58 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.4 X-MC-Unique: Oh1hnerzNmWeZq57PFf8Nw-1 From: Jiri Denemark To: devel@lists.libvirt.org Subject: [PATCH 2/2] NEWS: Mention migration bug with custom XML Date: Tue, 16 Apr 2024 19:53:26 +0200 Message-ID: <3eff41791b5dd882fbcf0a23dd7a1ddc9ef9a939.1713289982.git.jdenemar@redhat.com> In-Reply-To: References: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Message-ID-Hash: 53OWKGKT7OUVZJX7INPXFXIJVMW7WMHI X-Message-ID-Hash: 53OWKGKT7OUVZJX7INPXFXIJVMW7WMHI X-MailFrom: jdenemar@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-config-1; header-match-config-2; header-match-config-3; header-match-devel.lists.libvirt.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; suspicious-header X-Mailman-Version: 3.2.2 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZM-MESSAGEID: 1713290155171100001 Signed-off-by: Jiri Denemark Reviewed-by: Peter Krempa --- NEWS.rst | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/NEWS.rst b/NEWS.rst index c108e66f46..852dadf532 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -21,6 +21,14 @@ v10.3.0 (unreleased) =20 * **Bug fixes** =20 + * qemu: Fix migration with custom XML + + Libvirt 10.2.0 would sometimes complain about incompatible CPU definit= ion + when trying to migrate or save a domain and passing a custom XML even + though such XML was properly generated as migratable. Hitting this bug + depends on the guest CPU definition and the host on which a particular + domain was running. + =20 v10.2.0 (2024-04-02) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=20 2.44.0 _______________________________________________ Devel mailing list -- devel@lists.libvirt.org To unsubscribe send an email to devel-leave@lists.libvirt.org