From nobody Sun Dec 22 02:45:17 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; 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 8.43.85.245 as permitted sender) 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 1734113293391569.24218334059; Fri, 13 Dec 2024 10:08:13 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 996) id 3F870148A; Fri, 13 Dec 2024 13:08:12 -0500 (EST) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id 00757146B; Fri, 13 Dec 2024 13:07:49 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 996) id 004DD13FA; Fri, 13 Dec 2024 13:07:46 -0500 (EST) 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 B2226145D for ; Fri, 13 Dec 2024 13:07:45 -0500 (EST) Received: from mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-19-8Dgrd5_bOdiWF10MouzXzQ-1; Fri, 13 Dec 2024 13:07:44 -0500 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (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 mx-prod-mc-04.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6F1A519560B2 for ; Fri, 13 Dec 2024 18:07:43 +0000 (UTC) Received: from vhost3.router.laine.org (unknown [10.22.64.244]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 7B6AA1956086; Fri, 13 Dec 2024 18:07:42 +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.5 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1734113265; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=0hrH0OkD8nofB4rkqAjucaKMt4GsO519RtPMFj82KIE=; b=UNOtb+pHk3Apc5KlRMbv7dwkMqJkHjkbIDg2u7/wXe/YIzF+QQ4CyIfBhXGyI77TQUVEeK /v7qugeGxD7+NGE18Jp6W1+2JJ6uNVbrpRLqLqN0h8to0jMI92V9+QPSll1rS62daIr5Hg OspyYodzdH8J4kYt88otFBS9ssXNSQE= X-MC-Unique: 8Dgrd5_bOdiWF10MouzXzQ-1 X-Mimecast-MFC-AGG-ID: 8Dgrd5_bOdiWF10MouzXzQ From: Laine Stump To: devel@lists.libvirt.org Subject: [PATCH] qemu: allow migration of guest with mdev vGPU to VF vGPU Date: Fri, 13 Dec 2024 13:07:41 -0500 Message-ID: <20241213180741.1757708-1-laine@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: S_liw5IKMA9ZlnRynL_5icpcbo70rZtrzDKvhNZ0LvA_1734113263 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: 6R5D74ZGGZ7DFCM4RY4YVPD54SDHJ6N4 X-Message-ID-Hash: 6R5D74ZGGZ7DFCM4RY4YVPD54SDHJ6N4 X-MailFrom: laine@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 CC: Zhiyi Guo 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: X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1734113295580116600 Content-Type: text/plain; charset="utf-8"; x-default="true" GPU vendors are moving away from using mdev to create virtual GPUs towards using SRIOV VFs that are vGPUs. In both cases, once created the vGPUs are assigned to guests via (i.e. VFIO device assignment), and inside the guest the devices look identical, but mdev vGPUs are located by QEMU/VFIO using a uuid, while VF vGPUs are located with a PCI address. So although we generally require the device on the source host to exactly match the device on the destination host, in the case of mdev-created vGPU vs. VF vGPU migration *can* potentially work, except that libvirt has a hard-coded check that prevents us from even trying. This patch loosens up that check so that we will allow attempts to migrate a guest from a source host that has mdev-created vGPUs to a destination host that has VF vGPUs (and vice versa). The expectation is that if this doesn't actually work then QEMU will fail and generate an error that we can report. Based-on-patch-by: Zhiyi Guo Signed-off-by: Laine Stump --- Zhiyi's original patch removed the check for subsys type completely, and this worked. My modified patch keeps the check in place, but allows it to pass if the src type is pci and dst is mdev, or vice versa. src/conf/domain_conf.c | 28 +++++++++++++++++++++------- 1 file changed, 21 insertions(+), 7 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 4ad8289b89..9d5fda0469 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -20647,13 +20647,27 @@ virDomainHostdevDefCheckABIStability(virDomainHos= tdevDef *src, return false; } =20 - if (src->mode =3D=3D VIR_DOMAIN_HOSTDEV_MODE_SUBSYS && - src->source.subsys.type !=3D dst->source.subsys.type) { - virReportError(VIR_ERR_CONFIG_UNSUPPORTED, - _("Target host device subsystem %1$s does not match= source %2$s"), - virDomainHostdevSubsysTypeToString(dst->source.subs= ys.type), - virDomainHostdevSubsysTypeToString(src->source.subs= ys.type)); - return false; + if (src->mode =3D=3D VIR_DOMAIN_HOSTDEV_MODE_SUBSYS) { + virDomainHostdevSubsysType srcType =3D src->source.subsys.type; + virDomainHostdevSubsysType dstType =3D dst->source.subsys.type; + + /* If the source and destination subsys types aren't the same, + * then migration can't be supported, *except* that it might + * be supported to migrate from subsys type 'pci' to 'mdev' + * and vice versa. (libvirt can't know for certain whether or + * not it will actually work, so we have to just allow it and + * count on QEMU to provide us with an error if it fails) + */ + + if (srcType !=3D dstType + && ((srcType !=3D VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI && srcTyp= e !=3D VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV) + || (dstType !=3D VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI && dst= Type !=3D VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_MDEV))) { + virReportError(VIR_ERR_CONFIG_UNSUPPORTED, + _("Target host device subsystem type %1$s is no= t compatible with source subsystem type %2$s"), + virDomainHostdevSubsysTypeToString(dstType), + virDomainHostdevSubsysTypeToString(srcType)); + return false; + } } =20 if (!virDomainDeviceInfoCheckABIStability(src->info, dst->info)) --=20 2.47.1