mirror of
https://gitlab.com/libvirt/libvirt.git
synced 2024-07-30 13:37:17 +00:00
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.
ac2797cf2a
This patch resolves: https://bugzilla.redhat.com/show_bug.cgi?id=889319 When assigning an SRIOV virtual function to a guest using "intelligent PCI passthrough" (<interface type='hostdev'>, which sets the MAC address and vlan tag of the VF before passing its info to qemu), libvirt first learns the current MAC address and vlan tag by sending an NLM_F_REQUEST message for the VF's PF (physical function) to the kernel via a NETLINK_ROUTE socket (see virNetDevLinkDump()); the response message's IFLA_VFINFO_LIST section is examined to extract the info for the particular VF being assigned. This worked fine with kernels up until kernel commit 115c9b81928360d769a76c632bae62d15206a94a (first appearing in upstream kernel 3.3) which changed the ABI to not return IFLA_VFINFO_LIST in the response until a newly introduced IFLA_EXT_MASK field was included in the request, with the (newly introduced, of course) RTEXT_FILTER_VF flag set. The justification for this ABI change was that new fields had been added to the VFINFO, causing NLM_F_REQUEST messages to fail on systems with large numbers of VFs if the requesting application didn't have a large enough buffer for all the info. The idea is that most applications doing an NLM_F_REQUEST don't care about VFINFO anyway, so eliminating it from the response would lower the requirements on buffer size. Apparently, the people who pushed this patch made the mistaken assumption that iproute2 (the "ip" command) was the only package that used IFLA_VFINFO_LIST, so it wouldn't break anything else (and they made sure that iproute2 was fixed. The logic of this "fix" is debatable at best (one could claim that the proper fix would be for the applications in question to be fixed so that they properly sized the buffer, which is what libvirt does (purely by virtue of using libnl), but it is what it is and we have to deal with it. In order for <interface type='hostdev'> to work properly on systems with a kernel 3.3 or later, libvirt needs to add the afore-mentioned IFLA_EXT_MASK field with RTEXT_FILTER_VF set. Of course we also need to continue working on systems with older kernels, so that one bit of code is compiled conditionally. The one time this could cause problems is if the libvirt binary was built on a system without IFLA_EXT_MASK which was subsequently updated to a kernel that *did* have it. That could be solved by manually providing the values of IFLA_EXT_MASK and RTEXT_FILTER_VF and adding it to the message anyway, but I'm uncertain what that might actually do on a system that didn't support the message, so for the time being we'll just fail in that case (which will very likely never happen anyway). |
||
|---|---|---|
| .gnulib@d245e6ddd6 | ||
| build-aux | ||
| daemon | ||
| docs | ||
| examples | ||
| gnulib | ||
| include | ||
| m4 | ||
| po | ||
| python | ||
| src | ||
| tests | ||
| tools | ||
| .dir-locals.el | ||
| .gitignore | ||
| .gitmodules | ||
| .mailmap | ||
| AUTHORS.in | ||
| autobuild.sh | ||
| autogen.sh | ||
| bootstrap | ||
| bootstrap.conf | ||
| cfg.mk | ||
| ChangeLog-old | ||
| configure.ac | ||
| COPYING.LIB | ||
| HACKING | ||
| libvirt.pc.in | ||
| libvirt.spec.in | ||
| Makefile.am | ||
| Makefile.nonreentrant | ||
| mingw-libvirt.spec.in | ||
| README | ||
| README-hacking | ||
| run.in | ||
| TODO | ||
LibVirt : simple API for virtualization
Libvirt is a C toolkit to interact with the virtualization capabilities
of recent versions of Linux (and other OSes). It is free software
available under the GNU Lesser General Public License. Virtualization of
the Linux Operating System means the ability to run multiple instances of
Operating Systems concurrently on a single hardware system where the basic
resources are driven by a Linux instance. The library aim at providing
long term stable C API initially for the Xen paravirtualization but
should be able to integrate other virtualization mechanisms if needed.
Daniel Veillard <veillard@redhat.com>