Bug 889319
Summary: | support for IFLA_EXT_MASK and RTEXT_FILTER_VF needs to be added to lib | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Laine Stump <laine> | |
Component: | libvirt | Assignee: | Laine Stump <laine> | |
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | |
Severity: | unspecified | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 6.3 | CC: | acathrow, agospoda, ajia, dallan, dyasny, dyuan, honzhang, jpirko, lwang, mjenner, mzhan, rkhan, rwu, tgraf, tlavigne, yupzhang | |
Target Milestone: | rc | |||
Target Release: | --- | |||
Hardware: | Unspecified | |||
OS: | Unspecified | |||
Whiteboard: | ||||
Fixed In Version: | libvirt-0.10.2-14.el6 | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | 889249 | |||
: | 893131 (view as bug list) | Environment: | ||
Last Closed: | 2013-02-21 07:29:20 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 895654 |
Description
Laine Stump
2012-12-20 19:45:41 UTC
The following were committed upstream: commit ac2797cf2af2fd0e64c58a48409a8175d24d6f86 Author: Laine Stump <laine> Date: Thu Dec 20 13:22:17 2012 -0500 util: fix functions that retrieve SRIOV VF info 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). commit 846770e5ff959f7819e2c32857598cb88e2e2f0e Author: Laine Stump <laine> Date: Thu Dec 20 14:52:41 2012 -0500 util: add missing error log messages when failing to get netlink VFINFO This patch fixes the lack of error messages when libvirt fails to find VFINFO in a returned netlinke response message. https://bugzilla.redhat.com/show_bug.cgi?id=827519#c10 is an example of the error message that was previously logged when the IFLA_VFINFO_LIST object was missing from the netlink response. The reason for this failure is detailed in https://bugzilla.redhat.com/show_bug.cgi?id=889319 Even though that root problem has been fixed, the experience of finding the root cause shows us how important it is to properly log an error message in these cases. This patch *seems* to replace the entire function, but really most of the changes are due to moving code that was previously inside an if() statement out to the top level of the function (the original if() was reversed and made to log an error and return). The first patch above was incomplete/incorrect, requiring a 3rd patch, which has been committed upstream: commit 7c36650699f33e54361720f824efdf164bc6e65d Author: Laine Stump <laine> Date: Fri Dec 21 15:09:33 2012 -0500 util: fix botched check for new netlink request filters This is an adjustment to the fix for https://bugzilla.redhat.com/show_bug.cgi?id=889319 to account for two bonehead mistakes I made. commit ac2797cf2af2fd0e64c58a48409a8175d24d6f86 attempted to fix a problem with netlink in newer kernels requiring an extra attribute with a filter flag set in order to receive an IFLA_VFINFO_LIST from netlink. Unfortunately, the #ifdef that protected against compiling it in on systems without the new flag went a bit too far, assuring that the new code would *never* be compiled, and even if it had, the code was incorrect. The first problem was that, while some IFLA_* enum values are also their existence at compile time, IFLA_EXT_MASK *isn't* #defined, so checking to see if it's #defined is not a valid method of determining whether or not to add the attribute. Fortunately, the flag that is being set (RTEXT_FILTER_VF) *is* #defined, and it is never present if IFLA_EXT_MASK isn't, so it's sufficient to just check for that flag. And to top it off, due to the code not actually compiling when I thought it did, I didn't realize that I'd been given the wrong arglist to nla_put() - you can't just send a const value to nla_put, you have to send it a pointer to memory containing what you want to add to the message, along with the length of that memory. Verify it as follows. the result is expected. Change its status to VERIFIED. # uname -r 2.6.32-349.el6.x86_64 # rpm -q libvirt qemu-kvm libvirt-0.10.2-14.el6.x86_64 qemu-kvm-0.12.1.2-2.344.el6.x86_64 # lspci |grep Ethernet 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 05) 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection 09:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 09:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01) 0a:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0a:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0a:10.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) 0a:10.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01) ....... Add the following xml to guest <interface type='hostdev' managed='yes'> <mac address='52:54:00:ab:8d:40'/> <source> <address domain='0x0000' bus='0x0a' slot='0x10' function='0x0'/> </source> </interface> # virsh start rhel63 Domain rhel63 started # virsh dumpxml rhel63 <domain type='kvm' id='4'> <name>rhel63</name> ...... <devices> ...... <interface type='network'> <mac address='52:54:00:d7:f0:f2'/> <source network='default'/> <target dev='vnet0'/> <model type='rtl8139'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <interface type='hostdev' managed='yes'> <mac address='52:54:00:60:6e:2d'/> <source> <address type='pci' domain='0x0000' bus='0x0a' slot='0x10' function='0x0'/> </source> <alias name='hostdev0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </interface> ...... </devices> ...... </domain> Login guest , Check the Virtual Function using lspci.it exists. # virsh detach-interface rhel63 --type hostdev --mac 52:54:00:60:6e:2d Interface detached successfully The VF has been detached from guest. # virsh dumpxml rhel63 <domain type='kvm' id='5'> ....... <interface type='network'> <mac address='52:54:00:d7:f0:f2'/> <source network='default'/> <target dev='vnet0'/> <model type='rtl8139'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> ....... </domain> (In reply to comment #6) > Verify it as follows. the result is expected. Change its status to VERIFIED. > > # uname -r > 2.6.32-349.el6.x86_64 > > # rpm -q libvirt qemu-kvm > libvirt-0.10.2-14.el6.x86_64 > qemu-kvm-0.12.1.2-2.344.el6.x86_64 > > # lspci |grep Ethernet > 00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network > Connection (rev 05) > 01:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network > Connection > 09:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network > Connection (rev 01) > 09:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network > Connection (rev 01) > 0a:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev > 01) > 0a:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev > 01) > 0a:10.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev > 01) > 0a:10.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev > 01) > ....... > > Add the following xml to guest > <interface type='hostdev' managed='yes'> > <mac address='52:54:00:60:6e:2d'/> > <source> > <address domain='0x0000' bus='0x0a' slot='0x10' function='0x0'/> > </source> > </interface> Because I copy the xml from another file. the mac address is different in above steps. Actually it is the same always . It is typo. Revise it in the comment. > # virsh start rhel63 > Domain rhel63 started > > # virsh dumpxml rhel63 > <domain type='kvm' id='4'> > <name>rhel63</name> > ...... > <devices> > ...... > <interface type='network'> > <mac address='52:54:00:d7:f0:f2'/> > <source network='default'/> > <target dev='vnet0'/> > <model type='rtl8139'/> > <alias name='net0'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x03' > function='0x0'/> > </interface> > <interface type='hostdev' managed='yes'> > <mac address='52:54:00:60:6e:2d'/> > <source> > <address type='pci' domain='0x0000' bus='0x0a' slot='0x10' > function='0x0'/> > </source> > <alias name='hostdev0'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x07' > function='0x0'/> > </interface> > ...... > </devices> > ...... > </domain> > > > Login guest , Check the Virtual Function using lspci.it exists. > > > # virsh detach-interface rhel63 --type hostdev --mac 52:54:00:60:6e:2d > Interface detached successfully > > > The VF has been detached from guest. > > # virsh dumpxml rhel63 > <domain type='kvm' id='5'> > ....... > <interface type='network'> > <mac address='52:54:00:d7:f0:f2'/> > <source network='default'/> > <target dev='vnet0'/> > <model type='rtl8139'/> > <alias name='net0'/> > <address type='pci' domain='0x0000' bus='0x00' slot='0x03' > function='0x0'/> > </interface> > ....... > </domain> Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0276.html |