From xen-devel (Simon Horman):
I am happy to announce a refreshed backport of the IGB driver to linux-2.6.18-xen.
To allow the creation of virtual functions (VF) on the 82576 that can be passed through to domUs. This back-port is successful in that regard.
The current igb driver in linux-2.6.18-xen seems to be a back-port of a driver from RHEL5 that predates anything present in Linus’s kernel tree.
This makes back-porting of changes from Linus’s tree difficult. In particular, the original commit to Linus’s tree includes multi-queue support, a non-trivial feature, whereas the code currently in linux-2.6.18-xen does not.
With this in mind the method used was to back-port the original commit made to Linus’s tree and then back-port subsequent commits to Linus’s tree.
Although somewhat verbose this method appears to have worked quite well.
Some patches were not back-ported, in particular GRO. This is because the back-port seemed to be quite difficult for little gain. I’m happy to re-consider any non-back-ported patches if there is interest.
In total there are 191 patches on top of linux-2.6.18-xen
“xen/x86: make do_settimeofday() return -EPERM when clock can’t be changed”
(930:506133327116). Apart from one patch written by myself they all correspond to patches in Linus’s kernel tree. Where the patches have been modified I have noted this in the changelog and added my own Signed-off-by line. The majority of patches are unmodified.
Due to the large number of patches I am providing this backport as an hg tree, http://hg.vergenet.net/xen/linux-2.6.18-xen-igb
At this time it should be possible to pull this tree into linux-2.6.18-xen or to use it independently.
I am happy to post the patches to xen-devel if that is of value.
However my experience in the past has shown that posting more than a handful of patches results in a re-send-fest due to mangling issues.
There is also an issue that the first patch “igb: port to driver originally committed to Linus’s tree” (931:6b25a2daf6bc) is rather large at 192Kbytes.
* This back-port does not include the VF driver (igbvf). This means that VFs created using the igb driver can’t be used by dom0. They can, however, be passed through to domUs.
* removing the igb module while a VF is passed-through results in a hypervisor panic. This is after several pciback messages which explain that you have done something that you sholdn’t.
pciback: ****** removing device 0000:02:10.1 while still in-use! ******
pciback: ****** driver domain may still access this device’s i/o resources!
pciback: ****** shutdown driver domain before binding device
pciback: ****** to other drivers or domains
(XEN) [VT-D]iommu.c:1271:d0 domain_context_unmap:PCIe: bdf = 2:10.1
(XEN) Xen BUG at msi.c:776
* The tree does not compile with PCI_IOV enabled between changesets
- “igb: this patch addes the sr-iov enablement option via num_vfs parameter”
- “igb: remove sysfs entry that was used to set the number of vfs”
This is because the first patch makes use of netdev->dev which does not exist. However the need for this is removed by the second patch.