From nobody Sun May 19 02:06:41 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 63.128.21.124 as permitted sender) client-ip=63.128.21.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 63.128.21.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1614137736; cv=none; d=zohomail.com; s=zohoarc; b=Izsrtamk9ZkyZBpJ0r34iMIyMi8LekBx9ayYOM0t8V+T7bym43DmLh1EESUdaFzu3oRIxTi4dsV4GQojb+QgfnnhIEAMXaCK75Go5piKUTFtfQbg04vo3HD8twLDqSTa/jCPTlT+JziPCjESvzCnB8ZPTBvSNaM5Fc/uryrp/Ns= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1614137736; h=Content-Type:Content-Transfer-Encoding:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To; bh=D23uNgSTB1mCUhv3KCun6/umi7NkSREVP3itUBVkQLw=; b=EculIJLwXrjwFTpk7D2jIhw6gpAbppijq4sXjJlgCZeHIuGzKDyZVRlnOpCjxzM6ghxBDiOVRTFj59JN0LVtR7ExdI6q5INkvinxVd6qSoKCcVv8dtMzScFrzbbQCLcQXRJUyI6KYY01c1iaTAVUJyOWIhZMl1fv/o6R5bhAcnQ= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; spf=pass (zohomail.com: domain of redhat.com designates 63.128.21.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by mx.zohomail.com with SMTPS id 1614137736312685.4017623367909; Tue, 23 Feb 2021 19:35:36 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-350-zX98o7YMOmSlSgD6e8jLrg-1; Tue, 23 Feb 2021 22:35:20 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8E7B886A06B; Wed, 24 Feb 2021 03:35:14 +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 963081001281; Wed, 24 Feb 2021 03:35:12 +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 E862D4E58D; Wed, 24 Feb 2021 03:35:09 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 11O3Z8sm011224 for ; Tue, 23 Feb 2021 22:35:08 -0500 Received: by smtp.corp.redhat.com (Postfix) id D53C12C01F; Wed, 24 Feb 2021 03:35:08 +0000 (UTC) Received: from vhost2.router.laine.org (ovpn-112-184.phx2.redhat.com [10.3.112.184]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9DE7E1899A for ; Wed, 24 Feb 2021 03:35:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1614137735; h=from:from:sender:sender: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:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=D23uNgSTB1mCUhv3KCun6/umi7NkSREVP3itUBVkQLw=; b=HxBPibzkC3FTBStKtQOz1DNaOoPm1fgH/UShFB+0P49Dgo+OGUBXYq2x7jxubNGbHqJ3mZ li5JKMfqUuwMzkQGtWhCEs0IvlUj1XPs7wXK1FRp5jWB7zo+TTgbdOQlQvcAaU77Gzp4lO W1b1W0nkL/gOArINV9AI4wmMzudQk+Y= X-MC-Unique: zX98o7YMOmSlSgD6e8jLrg-1 From: Laine Stump To: libvir-list@redhat.com Subject: [libvirt PATCH] util: don't log error if SRIOV PF has no associated netdev Date: Tue, 23 Feb 2021 22:35:04 -0500 Message-Id: <20210224033504.740988-1-laine@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-loop: libvir-list@redhat.com 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: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @redhat.com) Content-Type: text/plain; charset="utf-8" Some SRIOV PFs don't have a netdev associated with them (the spec apparently doesn't require it). In most cases when libvirt is dealing with an SRIOV VF, that VF must have a PF, and the PF *must* have an associated netdev (the only way to set the MAC address of a VF is by sending a netlink message to the netdev of that VF's PF). But there are times when we don't need for the PF to have a netdev; in particular, when we're just getting the Switchdev Features for a VF, we don't need the PF netdev - the netdev of the VF (apparently) works just as well. Commit 6452e2f5 (libvirt 5.1.0) *kind of* made libvirt work around PFs with no netdevs in this case - if virNetDevGetPhysicalFunction returned an error when setting up to retrieve Switchdev feature info, it would ignore the error, and then check if the PF netdev name was NULL and, if so it would reset the error object and continue on rather than returning early with a failure. The problem is that by the time this special handling occured, the error message about missing netdev had already been logged, which was harmless to proper operation, but confused the user. Fortunately there are only 2 users of virNetDevGetPhysicalFunction, so it is easy to redefine it's API to state that a missing netdev name is *not* an error - in that case it will still return success, but the caller must be prepared for the PF netdev name to be NULL. After making this change, we can modify the two callers to behave properly with the new semantics (for one of the callers it *is* still an error, so the error message is moved there, but for the other it is okay to continue), and our spurious error messages are a thing of the past. Resolves: https://bugzilla.redhat.com/1924616 Fixes: 6452e2f5e1837bd753ee465e6607ed3c4f62b815 Signed-off-by: Laine Stump Reviewed-by: Michal Privoznik --- src/util/virnetdev.c | 31 +++++++++++++++---------------- 1 file changed, 15 insertions(+), 16 deletions(-) diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index 2b4c8b6280..7b766234ec 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -1339,7 +1339,8 @@ virNetDevGetVirtualFunctionIndex(const char *pfname, = const char *vfname, * * @ifname : name of the physical function interface name * @pfname : Contains sriov physical function for interface ifname - * upon successful return + * upon successful return (might be NULL if the PF has no + * associated netdev. This is *not* an error) * * Returns 0 on success, -1 on failure * @@ -1361,15 +1362,6 @@ virNetDevGetPhysicalFunction(const char *ifname, cha= r **pfname) return -1; } =20 - if (!*pfname) { - /* The SRIOV standard does not require VF netdevs to have - * the netdev assigned to a PF. */ - virReportError(VIR_ERR_INTERNAL_ERROR, - _("The PF device for VF %s has no network device na= me"), - ifname); - return -1; - } - return 0; } =20 @@ -1442,6 +1434,17 @@ virNetDevGetVirtualFunctionInfo(const char *vfname, = char **pfname, if (virNetDevGetPhysicalFunction(vfname, pfname) < 0) return -1; =20 + if (!*pfname) { + /* The SRIOV standard does not require VF netdevs to have the + * netdev assigned to a PF, but our method of retrieving + * VFINFO does. + */ + virReportError(VIR_ERR_INTERNAL_ERROR, + _("The PF device for VF %s has no network device na= me, cannot get virtual function info"), + vfname); + return -1; + } + if (virNetDevGetVirtualFunctionIndex(*pfname, vfname, vf) < 0) goto cleanup; =20 @@ -3204,12 +3207,8 @@ virNetDevSwitchdevFeature(const char *ifname, if ((is_vf =3D virNetDevIsVirtualFunction(ifname)) < 0) return ret; =20 - if (is_vf =3D=3D 1) { - /* Ignore error if PF does not have netdev assigned. - * In that case pfname =3D=3D NULL. */ - if (virNetDevGetPhysicalFunction(ifname, &pfname) < 0) - virResetLastError(); - } + if (is_vf =3D=3D 1 && virNetDevGetPhysicalFunction(ifname, &pfname) < = 0) + return ret; =20 pci_device_ptr =3D pfname ? virNetDevGetPCIDevice(pfname) : virNetDevGetPCIDevice(ifname); --=20 2.29.2