pci: properly handle out-of-order SRIOV virtual functions
This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1025397 When virPCIGetVirtualFunctions created the list of an SRIOV Physical Function's (PF) Virtual Functions (VF), it had assumed that the order of "virtfn*" links returned by readdir() from the PF's sysfs directory was already in the correct order. Experience has shown that this is not always the case - it can be in alphabetical order (which would e.g. place virtfn11 before virtfn2) or even some seemingly random order (see the example in the bugzilla report) This results in 1) incorrect assumptions made by consumers of the output of the virt_functions list of virsh nodedev-dumpxml, and 2) setting MAC address and vlan tag on the wrong VF (since libvirt uses netlink to set mac address and vlan tag, netlink requires the VF#, and the function virPCIGetVirtualFunctionIndex() returns the wrong index due to the improperly ordered VF list). The solution provided by this patch is for virPCIGetVirtualFunctions to no longer scan the entire device directory in its natural order, but instead to check for links individually by name "virtfn%d" where %d starts at 0 and increases with each success. Since VFs are created contiguously by the kernel, this will guarantee that all VFs are found, and placed in the arry in the correct order. One note of use to the uninitiated is that VIR_APPEND_ELEMENT always either increments *num_virtual_functions or fails, so no this isn't an endless loop. (NB: the SRIOV_* defines at the top of virpci.c were removed because they are unnecessary and/or not used.)
Showing
想要评论请 注册 或 登录