On 5/11/2016 8:35 AM, Alejandro Lucero wrote: > On Tue, May 10, 2016 at 4:59 PM, Stephen Hemminger < > stephen at networkplumber.org> wrote: > >> On Tue, 10 May 2016 19:21:41 +0800 >> Zhe Tao <zhe.tao at intel.com> wrote: >> >>> Problem: >>> The following operations will cause the igb_uio based DPDK >>> operation failed. >>> --Any device assignment through the kvm_assign_device interface, >>> this can be the pci-assign method in QEMU >>> --VFIO group attachment operation(attach to the container) >>> this can happens in vfio-pci assignment in QEMU >> >> >> If you have an IOMMU why not use VFIO instead, it is better. >> > > It is not about VFIO against UIO but about how iommu domains are created > and destroyed by the (old) kernel when iommu=pt. So even with VFIO you can > have problems.
Problem is in IOMMU driver but we are adding a workaround to igb_uio, if using VFIO solves the issue, I believe that is better workaround. 1) Is there any case IOMMU supported but VFIO is not supported? Is there anything forces to use igb_uio? 2) Does using VFIO solves the issue defined in problem statement? > > We have had problems like this and other due to our device (NFP) just > mapping up to 40 bits of address space. Old kernels used in LTS > distributions like Ubuntu are iommu buggy and you need to do things like > this mapping inside the driver for solving problems. By the way, using > SRIOV just adds more problems. It is not safe to use iommu=pt with 3.13.x > Ubuntu kernels. > > It would be a good thing for the original patch to identify those kernels > where the problem was detected. Of course, there could be more kernels with > the same problem but that is more work to do. > Thanks, ferruh
