From nobody Thu Dec 26 19:07:41 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 1732736286866272.23977834671257; Wed, 27 Nov 2024 11:38:06 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 996) id 2DBF2E69; Wed, 27 Nov 2024 14:38:06 -0500 (EST) Received: from lists.libvirt.org (localhost [IPv6:::1]) by lists.libvirt.org (Postfix) with ESMTP id E4DDF17E0; Wed, 27 Nov 2024 14:37:43 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 996) id 03E0B17D4; Wed, 27 Nov 2024 14:37:41 -0500 (EST) 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 6D03E177B for ; Wed, 27 Nov 2024 14:37:40 -0500 (EST) Received: from mx-prod-mc-02.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-14-BXkFQhjNMfapgqD3mLyoGA-1; Wed, 27 Nov 2024 14:37:38 -0500 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (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-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 687F61955F43 for ; Wed, 27 Nov 2024 19:37:37 +0000 (UTC) Received: from vhost3.router.laine.org (unknown [10.22.88.111]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id F060A19560A3 for ; Wed, 27 Nov 2024 19:37:36 +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.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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=1732736260; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=wuT4suQTAutHfqJQtIa/o4tPEFbKjMKLx8ab27QGB54=; b=i6zxHQYsAoPGD10J8EoaVNiL3FQwDSqfSfZMCk5EPyJml0ZPBKGuTFywegqe4qYIihtxVp tKH24Vydbe0vcU1Vwdq2D4A+DunQ2tQgsAMGtuA+jJgLl05AA9WA0csXtZfN+TK2jt2O7U 9UwJd1BVnpeBOe7xewPmDq0935sFoJ4= X-MC-Unique: BXkFQhjNMfapgqD3mLyoGA-1 X-Mimecast-MFC-AGG-ID: BXkFQhjNMfapgqD3mLyoGA From: Laine Stump To: devel@lists.libvirt.org Subject: [PATCH safe for 10.10.0] qemu: re-use existing ActualNetDef for more interface types during update-device Date: Wed, 27 Nov 2024 14:34:35 -0500 Message-ID: <20241127193736.972459-1-laine@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: MhVa24zDFZgspEcYgXopmZv9seT7DrcE40di36_RaeM_1732736257 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: RQ43NDXZ3WU7XPFHEA5REIYJODRHNK2Z X-Message-ID-Hash: RQ43NDXZ3WU7XPFHEA5REIYJODRHNK2Z 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 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: 1732736287639019100 Content-Type: text/plain; charset="utf-8"; x-default="true" For the full history behind this patch, look at the following: https://issues.redhat.com/browse/RHEL-7036 commit v10.7.0-101-ga37bd2a15b commit v10.8.0-rc2-8-gbcd5ae4e73 Summary: original problem was unexpected failure of update-device when the user hadn't changed anything other than online status of the guest NIC (which should always be allowed). The first commit "fixed" this by avoiding the allocation of a new ActualNetDef (i.e. creating a new networkport) for *all* network device updates (because that was inappropriately changing which ethernet physdev should be used for a macvtap connection, which by design can't be handled in an update-device). But this commit caused a regression for update-device of bridge-based network devices (because some the updates of certain attributes *do* require the ActualNetDef be re-allocated), so... The 2nd commit narrowed the list of network types that get the "don't allocate new ActualNetDef" treatment (so that only interfaces connected to a network that uses a pool of ethernet VFs *being used in passthrough mode* qualify). But then it was pointed out that this re-broke simple updates of devices that used a direct/macvtap network in "bridge" mode (because it's possible to list multiple physdevs to use for bridge mode, in which case the network driver attempts to "load balance" (and so a new allocation might have a different ethernet physdev which, again, can't be supported in a device-update). So this (single line of code) patch *widens* the list of network types that don't allocate a new ActualNetDef to also include the other direct (macvtap) modes, e.g. bridge, private, etc. Signed-off-by: Laine Stump Reviewed-by: Michal Privoznik --- There is a more comprehensive fix that also, e.g., makes updating the bandwidth or vlan info of a direct interface work correctly, but that is much more invasive (and also isn't done yet). This patch fixes the case of updating a direct interface's online status (for example) without breaking anything else. src/qemu/qemu_hotplug.c | 38 +++++++++++++++++++++----------------- 1 file changed, 21 insertions(+), 17 deletions(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 3c18af6b0c..ff8c1263c6 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -3935,25 +3935,29 @@ qemuDomainChangeNet(virQEMUDriver *driver, if (newdev->type =3D=3D VIR_DOMAIN_NET_TYPE_NETWORK) { if (olddev->type =3D=3D VIR_DOMAIN_NET_TYPE_NETWORK && oldType =3D=3D VIR_DOMAIN_NET_TYPE_DIRECT && - virDomainNetGetActualDirectMode(olddev) =3D=3D VIR_NETDEV_MACV= LAN_MODE_PASSTHRU && STREQ(olddev->data.network.name, newdev->data.network.name)) { /* old and new are type=3D'network', and the network name - * hasn't changed *and* this is a network where each - * connection is allocated exclusive use of a VF - * device. In this case we *don't* want to get a new port - * ("actual device") from the network because attempting - * to allocate a new device would also allocate a - * new/different VF, causing the update to fail. And - * anyway we can use olddev's actualNetDef (since it - * hasn't changed). - * - * So instead we just duplicate *the pointer to* the - * actualNetDef from olddev to newdev so that comparisons - * of actualNetDef will show no change. If the update is - * successful, we will clear the actualNetDef pointer from - * olddev before destroying it (or if the update fails, - * then we need to clear the pointer from newdev before - * destroying it) + * hasn't changed *and* this is a "direct" network (a pool + * of 1 or more host ethernet devices where each guest + * interface is allocated one device that it connects to + * via macvtap. In this case we *don't* want to get a new + * port ("actual device") from the network because + * attempting to allocate a new device would also allocate + * a new/different ethernet, causing the update to fail + * (because the physical device of a macvtap-based + * interface can't be changed without completely + * unplugging and re-plugging the guest NIC). + + + * We can work around this issue by just re-using olddev's + * actualNetDef (since it hasn't changed) rather than + * allocating a new one. We just duplicate *the pointer + * to* the actualNetDef from olddev to newdev so that + * comparisons of actualNetDef will show no change. If the + * update is successful, we will clear the actualNetDef + * pointer from olddev before destroying it (or if the + * update fails, then we need to clear the pointer from + * newdev before destroying it) */ newdev->data.network.actual =3D olddev->data.network.actual; memcpy(newdev->data.network.portid, olddev->data.network.porti= d, --=20 2.47.0