From nobody Wed Apr 24 17:59:17 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zoho.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1498659985737204.17895779654282; Wed, 28 Jun 2017 07:26:25 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B056541A54; Wed, 28 Jun 2017 14:26:22 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7259318251; Wed, 28 Jun 2017 14:26:22 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id 1E9C03FADF; Wed, 28 Jun 2017 14:26:22 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id v5SEOmBh027460 for ; Wed, 28 Jun 2017 10:24:48 -0400 Received: by smtp.corp.redhat.com (Postfix) id 5E190892A3; Wed, 28 Jun 2017 14:24:48 +0000 (UTC) Received: from virval.usersys.redhat.com (unknown [10.43.2.187]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 30049892AF for ; Wed, 28 Jun 2017 14:24:43 +0000 (UTC) Received: by virval.usersys.redhat.com (Postfix, from userid 500) id 23F34100143; Wed, 28 Jun 2017 16:24:42 +0200 (CEST) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B056541A54 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=libvir-list-bounces@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com B056541A54 From: Jiri Denemark To: libvir-list@redhat.com Date: Wed, 28 Jun 2017 16:24:39 +0200 Message-Id: Mail-Followup-To: libvir-list@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH] qemu: Don't update CPU when checking ABI stability X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 28 Jun 2017 14:26:23 +0000 (UTC) X-ZohoMail: RSF_0 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" When checking ABI stability between two domain definitions, we first make migratable copies of them. However, we also asked for the guest CPU to be updated, even though the updated CPU is supposed to be already included in the original definitions. Moreover, if we do this on the destination host during migration, we're potentially updating the definition with according to an incompatible host CPU. While updating the CPU when checking ABI stability doesn't make any sense, it actually just worked because updating the CPU doesn't do anything for custom CPUs (only host-model CPUs are affected) and we updated both definitions in the same way. Less then a year ago commit v2.3.0-rc1~42 stopped updating the CPU in the definition we got internally and only the user supplied definition was updated. However, the same commit started updating host-model CPUs to custom CPUs which are not affected by the request to update the CPU. So it still seemed to work right, unless a user upgraded libvirt 2.2.0 to a newer version while there were some domains with host-model CPUs running on the host. Such domains couldn't be migrated with a user supplied XML since libvirt would complain: Target CPU mode custom does not match source host-model The fix is pretty straightforward, we just need to stop updating the CPU when checking ABI stability. https://bugzilla.redhat.com/show_bug.cgi?id=3D1463957 Signed-off-by: Jiri Denemark --- src/qemu/qemu_domain.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index 8e7404da6..d9357f20c 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -5926,7 +5926,6 @@ qemuDomainMigratableDefCheckABIStability(virQEMUDrive= rPtr driver, =20 =20 #define COPY_FLAGS (VIR_DOMAIN_XML_SECURE | \ - VIR_DOMAIN_XML_UPDATE_CPU | \ VIR_DOMAIN_XML_MIGRATABLE) =20 bool --=20 2.13.2 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list