lp:~dmitriis/+git/libvirt

Get this repository:
git clone https://git.launchpad.net/~dmitriis/+git/libvirt
Only Dmitrii Shcherbakov can upload to this repository. If you are Dmitrii Shcherbakov please log in for upload directions.

Branches

Name Last Modified Last Commit
2021-ignore-eperm-for-vid0 2021-11-18 17:12:12 UTC
Ignore EPERM on implicit clearing of VF VLAN ID

Author: Dmitrii Shcherbakov
Author Date: 2021-11-17 20:04:20 UTC

Ignore EPERM on implicit clearing of VF VLAN ID

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>

2021-vpd-and-ignore-eperm-for-vid0 2021-10-18 07:31:09 UTC
Ignore EPERM on attempts to clear VF VLAN ID

Author: Dmitrii Shcherbakov
Author Date: 2021-10-15 20:32:21 UTC

Ignore EPERM on attempts to clear VF VLAN ID

SmartNIC DPUs may not expose 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 as a part of that will fail.

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

This case should be handled gracefully and the EPERM for clearing a VLAN
ID should be ignored. Thus, virNetDevSetVfConfig is split into two
distinct functions. If clearing a VLAN ID fails with EPERM, the error
is simply ignored.

An alternative to this would be providing a higher level control plane
mechanism that would provide metadata about a device being remotely
managed in which case Libvirt would avoid trying to clear a VLAN ID.
This would be much more complicated to implement and maintain.

2021-vpd-attempt-6 2021-10-08 21:36:44 UTC
News: Add PCI VPD parser & capability notes

Author: Dmitrii Shcherbakov
Author Date: 2021-09-27 08:41:08 UTC

News: Add PCI VPD parser & capability notes

2021-vpd-attempt-4 2021-09-22 14:13:59 UTC
Add PCI VPD Capability Documentation

Author: Dmitrii Shcherbakov
Author Date: 2021-09-21 23:42:33 UTC

Add PCI VPD Capability Documentation

Describes the format of the newly added VPD capability and gives and
example for a real-world device.

2021-vpd-attempt-2 2021-09-01 23:20:00 UTC
Add a PCI/PCIe device VPD Capability

Author: Dmitrii Shcherbakov
Author Date: 2021-08-24 08:53:25 UTC

Add a PCI/PCIe device VPD Capability

Add support for deserializing the binary PCI/PCIe VPD format and
exposing VPD resources as XML elements in a new nested capability
of PCI/PCIe devices called 'vpd'.

The VPD format is specified in "I.3. VPD Definitions" in PCI specs
(2.2+) and "6.28.1 VPD Format" PCIe 4.0. As section 6.28 in PCIe 4.0
notes, the PCI Local Bus and PCIe VPD formats are binary compatible
and PCIe 4.0 merely started incorporating what was already present in
PCI specs.

Linux kernel exposes a binary blob in the VPD format via sysfs since
v2.6.26 (commit 94e6108803469a37ee1e3c92dafdd1d59298602f) which requires
a parser to interpret.

Signed-off-by: Dmitrii Shcherbakov <dmitrii.shcherbakov@canonical.com>

2021-vpd-candidate 2021-08-23 21:40:40 UTC
Add a missing RW resource test case

Author: Dmitrii Shcherbakov
Author Date: 2021-08-23 21:40:40 UTC

Add a missing RW resource test case

2021-vpd 2021-08-18 21:55:30 UTC
WIP VPD: Add xml2xml testing, fix encountered bugs

Author: Dmitrii Shcherbakov
Author Date: 2021-08-18 21:41:50 UTC

WIP VPD: Add xml2xml testing, fix encountered bugs

* Added a nodedev XML example with the VPD capability;
* Modified the RNG schema to take the VPD capability into account;
* Fixed a number of issues:
  * Removed extra whitespace when formatting a string resource;
  * Fixed enum usage (nick instead of value);
  * Fixed list pointer handling during XML parsing which resulted in an
    empty resource list upon parsing;
  * Added pointer stealing where necessary to avoid cases where field
    key and value strings were auto-freed.

17 of 7 results
This repository contains Public information 
Everyone can see this information.