[libvirt PATCH v4 3/3] Ignore EPERM on implicit clearing of VF VLAN ID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <dmitrii.shcherbakov@xxxxxxxxxxxxx>
---
 src/util/virnetdev.c  | 10 +++++++++-
 tests/virnetdevtest.c |  2 +-
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/src/util/virnetdev.c b/src/util/virnetdev.c
index 8a0d188413..5728932f9c 100644
--- a/src/util/virnetdev.c
+++ b/src/util/virnetdev.c
@@ -1632,12 +1632,20 @@ virNetDevSetVfVlan(const char *ifname, int vf, const int *vlanid)
     requestError = virNetDevSendVfSetLinkRequest(ifname, IFLA_VF_VLAN,
                                                  &ifla_vf_vlan, sizeof(ifla_vf_vlan));
 
-    if (requestError) {
+    /* If vlanid is NULL - we are attempting to implicitly clear an existing 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. */
+    if (requestError == -EPERM && vlanid == NULL) {
+        rc = 0;
+    } else if (requestError) {
         virReportSystemError(-requestError,
                              _("Cannot set interface vlanid to %d "
                                "for ifname %s vf %d"),
                              vlanToSet, ifname ? ifname : "(unspecified)", vf);
         rc = requestError;
+    } else {
+        rc = 0;
     }
     VIR_DEBUG("RTM_SETLINK %s vf %d vlanid=%d - %s",
               ifname, vf,
diff --git a/tests/virnetdevtest.c b/tests/virnetdevtest.c
index 5a787fa0f1..f969898b94 100644
--- a/tests/virnetdevtest.c
+++ b/tests/virnetdevtest.c
@@ -234,7 +234,7 @@ testVirNetDevSetVfVlan(const void *opaque G_GNUC_UNUSED)
     };
 
     const struct nullVlanTestCase nullVLANTestCases[] = {
-        { .ifname = "fakeiface-eperm", .vf_num = 1, .rc = -EPERM },
+        { .ifname = "fakeiface-eperm", .vf_num = 1, .rc = 0 },
         { .ifname = "fakeiface-eagain", .vf_num = 1, .rc = -EAGAIN },
         /* Successful requests with vlan id 0 need to have a zero return code. */
         { .ifname = "fakeiface-ok", .vf_num = 1, .rc = 0 },
-- 
2.32.0





[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux