mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-12-25 01:34:11 +03:00
Libvirt native C API and daemons
5b1c525b1f
virPCIGetNetName is used to get the name of the netdev associated with a particular PCI device. This is used when we have a VF name, but need the PF name in order to send a netlink command (e.g. in order to get/set the MAC address of the VF). In simple cases there is a single netdev associated with any PCI device, so it is easy to figure out the PF netdev for a VF - just look for the PCI device that has the VF listed in its "virtfns" directory; the only name in the "net" subdirectory of that PCI device's sysfs directory is the PF netdev that is upstream of the VF in question. In some cases there can be more than one netdev in a PCI device's net directory though. In the past, the only case of this was for SR-IOV NICs that could have multiple PF's per PCI device. In this case, all PF netdevs associated with a PCI address would be listed in the "net" subdirectory of the PCI device's directory in sysfs. At the same time, all VF netdevs and all PF netdevs have a phys_port_id in their sysfs, so the way to learn the correct PF netdev for a particular VF netdev is to search through the list of devices in the net subdirectory of the PF's PCI device, looking for the one netdev with a "phys_port_id" matching that of the VF netdev. But starting in kernel 5.8, the NVIDIA Mellanox driver began linking the VFs' representor netdevs to the PF PCI address [1], and so the VF representor netdevs would also show up in the net subdirectory. However, all of the devices that do so also only have a single PF netdev for any given PCI address. This means that the net directory of the PCI device can still hold multiple net devices, but only one of them will be the PF netdev (the others are VF representors): $ ls '/sys/bus/pci/devices/0000:82:00.0/net' ens1f0 eth0 eth1 In this case the way to find the PF device is to look at the "phys_port_name" attribute of each netdev in sysfs. All PF devices have a phys_port_name matching a particular regex (p[0-9]+$)|(p[0-9]+s[0-9]+$) Since there can only be one PF in the entire list of devices, once we match that regex, we've found the PF netdev. [1] - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/ commit/?id=123f0f53dd64b67e34142485fe866a8a581f12f1 Co-Authored-by: Moshe Levi <moshele@nvidia.com> Signed-off-by: Dmytro Linkin <dlinkin@nvidia.com> Reviewed-by: Adrian Chiris <adrianc@nvidia.com> Reviewed-by: Laine Stump <laine@redhat.com> |
||
|---|---|---|
| .ctags.d | ||
| .github | ||
| .gitlab/issue_templates | ||
| build-aux | ||
| ci | ||
| docs | ||
| examples | ||
| include | ||
| po | ||
| scripts | ||
| src | ||
| tests | ||
| tools | ||
| .color_coded.in | ||
| .ctags | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .gitmodules | ||
| .gitpublish | ||
| .mailmap | ||
| .ycm_extra_conf.py.in | ||
| AUTHORS.rst.in | ||
| config.h | ||
| configmake.h.in | ||
| CONTRIBUTING.rst | ||
| COPYING | ||
| COPYING.LESSER | ||
| gitdm.config | ||
| libvirt-admin.pc.in | ||
| libvirt-lxc.pc.in | ||
| libvirt-qemu.pc.in | ||
| libvirt.pc.in | ||
| libvirt.spec.in | ||
| meson_options.txt | ||
| meson.build | ||
| mingw-libvirt.spec.in | ||
| NEWS.rst | ||
| README.rst | ||
| run.in | ||
.. image:: https://gitlab.com/libvirt/libvirt/badges/master/pipeline.svg
:target: https://gitlab.com/libvirt/libvirt/pipelines
:alt: GitLab CI Build Status
.. image:: https://bestpractices.coreinfrastructure.org/projects/355/badge
:target: https://bestpractices.coreinfrastructure.org/projects/355
:alt: CII Best Practices
.. image:: https://translate.fedoraproject.org/widgets/libvirt/-/libvirt/svg-badge.svg
:target: https://translate.fedoraproject.org/engage/libvirt/
:alt: Translation status
==============================
Libvirt API for virtualization
==============================
Libvirt provides a portable, long term stable C API for managing the
virtualization technologies provided by many operating systems. It
includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware
vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER
Hypervisor.
For some of these hypervisors, it provides a stateful management
daemon which runs on the virtualization host allowing access to the
API both by non-privileged local users and remote users.
Layered packages provide bindings of the libvirt C API into other
languages including Python, Perl, PHP, Go, Java, OCaml, as well as
mappings into object systems such as GObject, CIM and SNMP.
Further information about the libvirt project can be found on the
website:
https://libvirt.org
License
=======
The libvirt C API is distributed under the terms of GNU Lesser General
Public License, version 2.1 (or later). Some parts of the code that are
not part of the C library may have the more restrictive GNU General
Public License, version 2.0 (or later). See the files ``COPYING.LESSER``
and ``COPYING`` for full license terms & conditions.
Installation
============
Instructions on building and installing libvirt can be found on the website:
https://libvirt.org/compiling.html
Contributing
============
The libvirt project welcomes contributions in many ways. For most components
the best way to contribute is to send patches to the primary development
mailing list. Further guidance on this can be found on the website:
https://libvirt.org/contribute.html
Contact
=======
The libvirt project has two primary mailing lists:
* libvirt-users@redhat.com (**for user discussions**)
* libvir-list@redhat.com (**for development only**)
Further details on contacting the project are available on the website:
https://libvirt.org/contact.html