aboutsummaryrefslogtreecommitdiffstats
path: root/src/vnet/lisp-gpe/lisp_gpe_adjacency.h
diff options
context:
space:
mode:
authorYulong Pei <yulong.pei@intel.com>2019-10-17 18:41:52 +0800
committerAndrew Yourtchenko <ayourtch@gmail.com>2019-11-15 07:11:04 +0000
commit1c2fd1609c321cc50b29573807c19e79621bcb5c (patch)
tree36dc242a85d0958356eb7498f86e5e1922131de1 /src/vnet/lisp-gpe/lisp_gpe_adjacency.h
parentab46b6a03b9c416f6fafe0a11bf82a0297b2b498 (diff)
vlib: linux: fix wrong iommu_group value issue when using dpdk-plugin
When VPP work with dpdk-plugin, linux_vfio_main_t->container_fd is always -1 since it never have chance to run open("/dev/vfio/vfio") to get the fd. But this lead to a potential issue of VPP, that is, when start VPP without uio-driver field setup in /etc/vpp/startup.conf, VPP will run to automatical select uio driver in vlib_pci_bind_to_uio() and the function depend on iommu_group value to decide to work on vfio or vfio-noiommu mode. Since in vlib_pci_get_device_info() have the condition container_fd != -1, so the iommu_group value will be always -1 at this scenario, this caused that VPP mistake to run with vfio-noiommu driver on intel_iommu=on state. Actually in order to get iommu_group and iommu_group/name value, no need to depend on linux_vfio_main_t->container_fd value, so the fix remove the condition lvm->container_fd != -1, then it can get the correct iommu_group value. Type: fix Change-Id: I3f162fc4971b9a2b8717205f8f3b52e30c5e5b69 Signed-off-by: Yulong Pei <yulong.pei@intel.com> (cherry picked from commit 45495480c8165090722389b08075df06ccfcd7ef)
Diffstat (limited to 'src/vnet/lisp-gpe/lisp_gpe_adjacency.h')
0 files changed, 0 insertions, 0 deletions