568efef729
Historically libvirt hasn't differentiated between the name of a loadable kernel module, and the name of the device driver that module implements, but these two names can be (and usually are) at least subtly different. For example, the loadable module called "vfio_pci" implements a PCI driver called "vfio-pci". We have always used the name "vfio-pci" both to load the module (with modprobe) and to check (in /sys/bus/pci/drivers) if the driver is available. (This has happened to work because modprobe "normalizes" all the names it is given by replacing "-" with "_", so "vfio-pci" works for both loading the module and checking for the driver.) When we recently gained the ability to manually specify the driver for "virsh nodedev-detach", the fragility of this system became apparent - if a user gave the "driver name" as "vfio_pci", then we would modprobe the module correctly, but then erroneously believe it hadn't been loaded because /sys/bus/pci/drivers/vfio_pci didn't exist. For manual specification of the driver name, we could deal with this by telling the user "always use the correct name for the driver, don't assume that it has the same name as the module", but it would still end up confusing people, especially since some drivers do use underscore in their name (e.g. the mlx5_vfio_pci driver/module). This will only get worse when an upcoming patch starts automatically determining the driver to use for VFIO-assigned devices - it will look in the kernel's modules.alias file to find "best" VFIO variant *module* for a device, and 3 out of 4 current examples of vfio-pci/variant drivers have a mismatch between module name and driver name, so the current code would end up properly loading the module, but then erroneously think that the driver wasn't available. This patch makes the code more forgiving by 1) checking for both $drivername and underscore($drivername) in /sys/bus/pci/drivers 2) when we determine a module needs to be loaded, look at the link in /sys/module/$modulename/driver/pci:$drivername to determine the name of the driver we need to bind to the device(rather than just assuming the driver has the same name as the module Signed-off-by: Laine Stump <laine@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com> |
||
|---|---|---|
| .ctags.d | ||
| .github/workflows | ||
| .gitlab/issue_templates | ||
| build-aux | ||
| ci | ||
| docs | ||
| examples | ||
| include | ||
| po | ||
| scripts | ||
| src | ||
| subprojects | ||
| tests | ||
| tools | ||
| .ctags | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| .gitmodules | ||
| .gitpublish | ||
| .mailmap | ||
| 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 | ||
| NEWS.rst | ||
| README.rst | ||
| run.in | ||
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:
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:
- users@lists.libvirt.org (for user discussions)
- devel@lists.libvirt.org (for development only)
Further details on contacting the project are available on the website: