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@canonical.com>
---
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 filled
with the desired key=value pairs.
+ * 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**
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, 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, whereas the Libvirt client has not
+ * explicitly configured a VLAN or requested it to be cleared via vid 0. */
+ if (requestError == -EPERM && vlanid == NULL) {
+ rc = 0;
+ } else if (requestError) {
virReportSystemError(-requestError,
_("Cannot set interface vlanid to %d "
"for ifname %s vf %d"),
ifla_vf_vlan.vlan, 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 f5f54653bb..d73eaec817 100644
--- a/tests/virnetdevtest.c
+++ b/tests/virnetdevtest.c
@@ -236,7 +236,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
On 2/1/22 09:28, Dmitrii Shcherbakov wrote: > 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@canonical.com> > --- > 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 filled > with the desired key=value pairs. > > + * 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** > Any NEWS.rst change MUST (in sense of RFC2119) be done in a separate patch. The reason is that when somebody backports these patches onto one of previous releases then they would get needless conflict only because of this file. > > 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, const int *vlanid) > requestError = virNetDevSendVfSetLinkRequest(ifname, IFLA_VF_VLAN, > &ifla_vf_vlan, sizeof(ifla_vf_vlan)); > Again, nothing technically wrong here, I had to adopt it to the changes I made to previous patches. Michal
> The reason is that when somebody backports these patches onto one of previous releases then they would get needless conflict only because of this file. Ack, I'll make a note of that for the future changes, thanks guiding me with this! Best Regards, Dmitrii Shcherbakov LP/MM/oftc: dmitriis On Wed, Feb 2, 2022 at 9:04 PM Michal Prívozník <mprivozn@redhat.com> wrote: > On 2/1/22 09:28, Dmitrii Shcherbakov wrote: > > 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@canonical.com> > > --- > > 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 > filled > > with the desired key=value pairs. > > > > + * 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** > > > > Any NEWS.rst change MUST (in sense of RFC2119) be done in a separate > patch. The reason is that when somebody backports these patches onto one > of previous releases then they would get needless conflict only because > of this file. > > > > > 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, > const int *vlanid) > > requestError = virNetDevSendVfSetLinkRequest(ifname, IFLA_VF_VLAN, > > &ifla_vf_vlan, > sizeof(ifla_vf_vlan)); > > > > Again, nothing technically wrong here, I had to adopt it to the changes > I made to previous patches. > > Michal > >
© 2016 - 2026 Red Hat, Inc.