From nobody Mon Feb 9 17:57:34 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) client-ip=170.10.129.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=fail(p=none dis=none) header.from=canonical.com Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.zohomail.com with SMTPS id 1643704579579846.8079674774763; Tue, 1 Feb 2022 00:36:19 -0800 (PST) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-623-EiVHTrSVM-y_zDjnO2aocA-1; Tue, 01 Feb 2022 03:36:15 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 17D361083F61; Tue, 1 Feb 2022 08:36:09 +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 A51F15ED50; Tue, 1 Feb 2022 08:36:07 +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 9FFBB4BB7C; Tue, 1 Feb 2022 08:36:03 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 2118Ymu3018487 for ; Tue, 1 Feb 2022 03:34:49 -0500 Received: by smtp.corp.redhat.com (Postfix) id AFF5740CFD20; Tue, 1 Feb 2022 08:34:48 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast08.extmail.prod.ext.rdu2.redhat.com [10.11.55.24]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ABB8340CFD07 for ; Tue, 1 Feb 2022 08:34:48 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 93B253806723 for ; Tue, 1 Feb 2022 08:34:48 +0000 (UTC) Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-320-IKqHE_hKNmCPTLzTd2x1zw-1; Tue, 01 Feb 2022 03:34:47 -0500 Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) (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 smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 171443F1A3 for ; Tue, 1 Feb 2022 08:28:57 +0000 (UTC) Received: by mail-lj1-f197.google.com with SMTP id u18-20020a2ea172000000b002393f377a13so5112851ljl.13 for ; Tue, 01 Feb 2022 00:28:57 -0800 (PST) Received: from ws.lan.d-node.is ([95.165.29.203]) by smtp.gmail.com with ESMTPSA id l5sm1074586lje.21.2022.02.01.00.28.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 01 Feb 2022 00:28:55 -0800 (PST) X-MC-Unique: EiVHTrSVM-y_zDjnO2aocA-1 X-MC-Unique: IKqHE_hKNmCPTLzTd2x1zw-1 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=YfEkvpPX3805UiZLC0AmTGUhJkrgH+UsgwoyDL7kSgk=; b=VWGsr6mBkEZOrYH0gY/o7SPQHIAObH8EXSMe4t8wzzt0v8MiSB0Rjx4TwjRAzqmAMC vtFGzyQFX0rG1RjRry2XsQqnyL+a0lAKf7u+74f+i5qm5wRnPE5eywUDL4ufyPio4nDh Byri7Qie0gvoq6wZeDz8JjKgsZwuoDalWPufrjf+i8EkgwmxH2o0Czw0ussJ7qKdMhlX 1lKrf4hw0KTQpeIVA9s/P40zEJh5vSJKcCIgn3iPANGW8C1YP6fLHydADksxFSa6Wrvi 6H6UpjDZZDYQ1nph5j3LdE4YsiLtMem3cfj0l3eLVSe6yr5wCXxGvN5h5REQWHnW7QRc Lp6w== X-Gm-Message-State: AOAM532Zkt257PhOIdJPwgOs1fMMgXhwHZhNFdyR8Du1z1VcVih531m2 xoreXrWJcYU7EU3pXyUXn8Wm3+/yxPA6Qw8D5NMK5GvSMKuyP2Qxe9yymg4v1LdLgDr2jJWYVIY k4eTDWiHaUPMAAH7Afs4AMvH5tw6us4d/vA== X-Received: by 2002:a05:6512:344a:: with SMTP id j10mr18580989lfr.467.1643704136507; Tue, 01 Feb 2022 00:28:56 -0800 (PST) X-Google-Smtp-Source: ABdhPJxug5bfC0UrIcs2evXObbRu5WYnXaww23+3IZGJ9hIzK3QlJhjxns55/QfrgI7xy1HlD+vwSg== X-Received: by 2002:a05:6512:344a:: with SMTP id j10mr18580978lfr.467.1643704136258; Tue, 01 Feb 2022 00:28:56 -0800 (PST) From: Dmitrii Shcherbakov To: dmitrii.shcherbakov@canonical.com, libvir-list@redhat.com Subject: [libvirt PATCH v8 3/3] Ignore EPERM on implicit clearing of VF VLAN ID Date: Tue, 1 Feb 2022 11:28:53 +0300 Message-Id: <20220201082853.147209-4-dmitrii.shcherbakov@canonical.com> In-Reply-To: <20220201082853.147209-1-dmitrii.shcherbakov@canonical.com> References: <20220201082853.147209-1-dmitrii.shcherbakov@canonical.com> MIME-Version: 1.0 X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.84 on 10.11.54.1 X-MIME-Autoconverted: from quoted-printable to 8bit by lists01.pubmisc.prod.ext.phx2.redhat.com id 2118Ymu3018487 X-loop: libvir-list@redhat.com Cc: laine@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.79 on 10.5.11.14 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-ZM-MESSAGEID: 1643704591967100001 Content-Type: text/plain; charset="utf-8" SmartNIC DPUs may not expose some privileged eswitch operations to the hypervisor hosts. For example, this happens with Bluefield devices running in the ECPF (default) mode for security reasons. While VF MAC address programming is possible via an RTM_SETLINK operation, trying to set a VLAN ID in the same operation will fail with EPERM. The equivalent ip link commands below provide an illustration: 1. This works: sudo ip link set enp130s0f0 vf 2 mac de:ad:be:ef:ca:fe 2. Setting (or clearing) a VLAN fails with EPERM: sudo ip link set enp130s0f0 vf 2 vlan 0 RTNETLINK answers: Operation not permitted 3. This is what Libvirt attempts to do today (when trying to clear a VF VLAN at the same time as programming a VF MAC). sudo ip link set enp130s0f0 vf 2 vlan 0 mac de:ad:be:ef:ca:fe RTNETLINK answers: Operation not permitted If setting an explicit VLAN ID results in an EPERM, clearing a VLAN (setting a VLAN ID to 0) can be handled gracefully by ignoring the EPERM error with the rationale being that if we cannot set this state in the first place, we cannot clear it either. In order to keep explicit clearing of VLAN ID working as it used to be passing a NULL pointer for VLAN ID is used. Signed-off-by: Dmitrii Shcherbakov --- NEWS.rst | 14 ++++++++++++++ src/util/virnetdev.c | 11 ++++++++++- tests/virnetdevtest.c | 2 +- 3 files changed, 25 insertions(+), 2 deletions(-) diff --git a/NEWS.rst b/NEWS.rst index 666a593b58..f5453257ab 100644 --- a/NEWS.rst +++ b/NEWS.rst @@ -34,6 +34,20 @@ v8.1.0 (unreleased) to parse sysconfig files, in case they are created by the admin and fi= lled with the desired key=3Dvalue pairs. =20 + * virnetdev: Ignore EPERM on implicit clearing of VF VLAN ID + + Libvirt will now ignore EPERM errors on attempts to implicitly clear a + VLAN ID (when a VLAN is not explicitly provided via an interface XML + using a 0 or a non-zero value) as SmartNIC DPUs do not expose VLAN + programming capabilities to the hypervisor host. This allows Libvirt + clients to avoid specifying a VLAN and expect VF configuration to work + since Libvirt tries to clear a VLAN in the same operation + as setting a MAC address for VIR_DOMAIN_NET_TYPE_HOSTDEV devices which + is now split into two distinct operations. EPERM errors received while + trying to program a non-zero VLAN ID or explicitly program a VLAN ID 0 + will still cause errors as before so there is no change in behavior + in those cases. + * **Bug fixes** =20 =20 diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c index eacdc3bf1f..cf9056f1bd 100644 --- a/src/util/virnetdev.c +++ b/src/util/virnetdev.c @@ -1613,12 +1613,21 @@ virNetDevSetVfVlan(const char *ifname, int vf, cons= t int *vlanid) requestError =3D virNetDevSendVfSetLinkRequest(ifname, IFLA_VF_VLAN, &ifla_vf_vlan, sizeof(ifl= a_vf_vlan)); =20 - if (requestError) { + /* If vlanid is NULL - we are attempting to implicitly clear an existi= ng VLAN id. + * An EPERM received at this stage is an indicator that the embedded + * switch is not exposed to this host and the network driver is not + * able to set a VLAN for a VF, whereas the Libvirt client has not + * explicitly configured a VLAN or requested it to be cleared via vid = 0. */ + if (requestError =3D=3D -EPERM && vlanid =3D=3D NULL) { + rc =3D 0; + } else if (requestError) { virReportSystemError(-requestError, _("Cannot set interface vlanid to %d " "for ifname %s vf %d"), ifla_vf_vlan.vlan, ifname ? ifname : "(unspec= ified)", vf); rc =3D requestError; + } else { + rc =3D 0; } VIR_DEBUG("RTM_SETLINK %s vf %d vlanid=3D%d - %s", ifname, vf, diff --git a/tests/virnetdevtest.c b/tests/virnetdevtest.c index f5f54653bb..d73eaec817 100644 --- a/tests/virnetdevtest.c +++ b/tests/virnetdevtest.c @@ -236,7 +236,7 @@ testVirNetDevSetVfVlan(const void *opaque G_GNUC_UNUSED) }; =20 const struct nullVlanTestCase nullVLANTestCases[] =3D { - { .ifname =3D "fakeiface-eperm", .vf_num =3D 1, .rc =3D -EPERM }, + { .ifname =3D "fakeiface-eperm", .vf_num =3D 1, .rc =3D 0 }, { .ifname =3D "fakeiface-eagain", .vf_num =3D 1, .rc =3D -EAGAIN }, /* Successful requests with vlan id 0 need to have a zero return c= ode. */ { .ifname =3D "fakeiface-ok", .vf_num =3D 1, .rc =3D 0 }, --=20 2.32.0